My notebook (Compaq Evo 800N with 1.8GHz P4) makes hearable sound when it runs VMware with 1000Hz clocks on both host and in the guest. Apparently Compaq did not thought about CPU changing its power consumption & power state 2000 times a second... As with 1000Hz gnome cpu monitor signalled that approx. 50% of time is spent in the kernel and 50% of time it is idle, I decreased HZ to get rid of that beeping I heard whenever guest was idle...

As bonus now system has much better latency it seems - though I cannot explain why decreasing HZ also decreases latency... So I believe that problem are ACPI state transitions and not VMware per-se, just VMware's bursty behavior confuses ACPI sufficiently to get mad (as it seems fine if I run 1000Hz guest on 100Hz kernel, only if kernel uses 1000Hz jiffies things go bad).

I ran in to the same problem on my SLES9 (2.6.5) virtual machines. I was unable to keep time synchronized with NTP at all - we use eDirectory which relies heavily on time synchronization so this effectively killed us until I could find a fix.

Like others here I changed guest HZ to 100 and was able to get time synchronization. Is there any negative effect to doing this on the host as well? I am using a PXE boot environment and keeping all the kernels the same simplifies management.

I tried with clock=tsc but I was unable to get ntp working with SLES9 (2.6.5). I ended up going back to my kernel compiled with HZ=100



I should also add that running a kernel with HZ=100 on the host AND guests causes WAY more clock jitter than running both with HZ=1000. The only combo that seems to work for me is HZ=100 for the guest and HZ=1000 for the host. It seems even with HZ=100 the clock jitter on my guests is much worse than a real clock - at least it is within NTP's spec however.

Message was edited by: linux_blade_guy

Reliability on our systems has been very poor due to this time synchronization problem. Before NTP would give up after about 20 minutes - now it holds timesync for a few days but eventually looses it.

This is a MAJOR problem for us - we may have to scrap our VMWare rollout. Hopefully they get this fixed or I'm certainly not going to tell anyone to run production 2.6 kernel servers on VMWare.

On the clock= question, I have some partial info, but it doesn't seem to mesh completely with everything that others have posted here.

The default in a vanilla 2.6 kernel is for Linux to try clock= options in the order cyclone, hpet, pmtmr, tsc, pit. The cyclone and hpet timers aren't present in a VM. The pmtmr is present, but I think Linux decides not to use it if you turn off ACPI support.

In SuSE SLES9, there is a patch that changes the preference order to put tsc in front of pmtmr. So the effect is that on SLES9 in a VM, you get clock=tsc by default, while in a vanilla 2.6 kernel in a VM you get clock=pmtmr by default.

Between 2.4 and 2.6, some complex code has been added to the routines that are used if clock=tsc. 2.4 didn't have the clock= option, but the code that is now under clock=tsc is what was used on all machines with TSCs. In my testing on SLES9, clock=tsc makes the clock run too fast in a VM. I'm going to have to read the Linux code much more carefully to find out why and whether we can do something to tame it.

The good news is that my SLES9 VM seems to keep time okay with clock=pmtmr. Using clock=pit should work too (though I haven't tried it yet), but that causes gettimeofday in the VM to be a lot more coarse-grained, so it seems preferable to use pmtmr if it works.

The thing that worries me here is that a previous poster (sindu) reported that using clock=tsc worked better than clock=pmtmr on Debian Sarge with its 2.6.8-1 kernel; however, later he said that clock=pit was still better. I can understand clock=pit being better than clock=tsc, but not why clock=pmtmr was worse than clock=tsc -- that doesn't reproduce for me. Maybe it's because SLES9 uses a 2.6.5-based kernel? Ugh.

I've completed some additional testing and study of the Linux code. The bottom line is that I have to recommend clock=pit. You'll also need to be sure that VMware Tools are installed and tools time sync is on, or else your clock will lose time in this mode.

There is a bug in the Linux 2.6 clock=tsc code, and a similar but less severe bug in clock=pmtmr, that can cause the clock to gain time. I'm not sure how often the bug hits on real hardware, but it hits frequently in a VM. VMware Tools aren't prepared to correct for the guest clock running too fast, so that makes these modes unusable. For details on the bug, see my post to the Linux kernel mailing list, at http://gossamer-threads.com/lists/linux/kernel/494604.

The bug is in code that tries to make up for lost clock interrupts ("ticks"). The code gets some false positives when trying to detect lost ticks and ends up adding extra ticks to the clock when it shouldn't. With clock=pit, there is no attempt to detect lost ticks, so this doesn't happen. Unfortunately some ticks really are lost, which is why you need to run VMware Tools time sync to keep the clock from running slow.