[CentOS-virt] tick divider bugs

Mon May 5 17:39:40 UTC 2008
Allen Tsang <atsang at advance.net>

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-0002.vcf>