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
[email protected]
http://lists.centos.org/mailman/listinfo/centos-virt
begin:vcard
fn:Allen Tsang
n:Tsang;Allen
org:Advance Internet;Systems Engineering
adr:;;30 Journal Square;Jersey City;NJ;07306;United States
email;internet:[EMAIL PROTECTED]
title:Systems Administrator
tel;work:2017931808
x-mozilla-html:FALSE
url:http://www.advance.net
version:2.1
end:vcard
_______________________________________________
CentOS-virt mailing list
[email protected]
http://lists.centos.org/mailman/listinfo/centos-virt
