Right, blog posts from 2006 always trump facts from running the latest supported kernel with totally different flags, amirite? I could show you a bunch of documentation from ESX 2.5 too, but that stuff is outdated and wrong. Try harder. FYI: """ kernel /vmlinuz-2.6.18-53.1.14.el5 ro root=/dev/RootDisk/root divider=10 notsc clocksource=acpi_pm """ I do the above in conjunction with tools.synctime="true". I've tried almost everything else under the sun with a number of test VMs on our ESX setup, and the best combination of low idle load and accurate timekeeping was achieved using that combination of settings. Yes, ntpd is off. Feel free to give it a shot; I don't take credit for it, I found notes about this on the CentOS bug tracker (http://bugs.centos.org/view.php?id=2189). Like other fine folks have mentioned on this list (much to their amusement likely, now), clocksource=pit is nice, but it doesn't work with divider=10 and hangs on boot. I know this is a confusing topic; a lot of things are changing on a monthly basis. But everyone is ganging up on me with all these weak arguments and... wow: http://xkcd.com/386/ Maybe you guys should run your own tests and present your findings instead?.. "Science!" Thanks for the heads up about the realtime kernel; looking forward to researching it, I hope performance isn't impacted. It is a classic CS/physics problem you know? "Updating things in N places at once using a single source with inherent scheduling conflicts with asymetrical loads..." - Allen Tsang Johnny Hughes wrote: > Allen Tsang wrote: >> Also just to review, clocksource=acpi_pm should be used in >> conjunction with the tools.synctime = "true" flag in your vmx file. >> The combination of the two settings prevents time from going into the >> future from too many ticks, and synctime corrects slow clocks, which >> leads to a much, much better clock sync. > > That (clocksource=acpi_pm) is ONLY the best method if your clock is > running SLOWER than normal .. and in fact, a "clocksource=pit" is > probably the best solution for a clock that is running FASTER than > normal. If the clock is running FASTER than normal, also getting the > max frequency (host.cpukHz) set per these instructions is important: > > http://blog.autoedification.com/2006/11/vmware-guest-clock-runs-fast.html > > The /proc/ location in that article is not correct for centos4 or > centos5, but you can probably get the correct info for frequency most > of the time from /proc/cpuinfo, dmesg, or dmidecode. > >> >> We'll have to wait until someone figures out a clever way to tie VM >> clock ticks to a multiplexed physical clock source; >> until then, clocksync will always be a problem without a complete >> solution (read up on it). This is as close as it gets! > > There is a potential fix in the Real Time Kernel () that Red Hat has > released as part of their beta MRG release in that it might the > support tickless option. I have not had time to look at this solution > yet, but the kernel SRPM is here if someone wants to: > > ftp://ftp.redhat.com/pub/redhat/linux/beta/MRG/RHEL-5/src/ > > <snip> > > Thanks, > Johnny Hughes > > ------------------------------------------------------------------------ > > _______________________________________________ > CentOS-virt mailing list > CentOS-virt at centos.org > http://lists.centos.org/mailman/listinfo/centos-virt > -------------- next part -------------- A non-text attachment was scrubbed... Name: atsang.vcf Type: text/x-vcard Size: 294 bytes Desc: not available URL: <http://lists.centos.org/pipermail/centos-virt/attachments/20080505/ed33ad38/attachment-0004.vcf>