BTW, the host is configured for 250 Hz (4ms):
% gunzip -c /proc/config.gz | grep CONFIG_HZ
I have the same situation. Both WinXP and Linux guests are running way fast.
No published fixes have had any effect. I first noticed the problem when I went to v1.0.3 and 64-bit and a dual-core host.
I am running 1.0.2 on 64-bit SLES 9 on a single-core AMD Athlon64 with no problems. WinXP guests stay right on target.
Well, I hate to say it, but this is the "never ending question". If we could get a good, definitive answer on this one, I'd be overjoyed.
I'm running on a Dell 6650 with 3 physical CPUs (6 cores) with Ubuntu 7.04 on the physical hardware (no skew), vmware server 1.0.3(?) and seeing time skew of about 1.5x on guests running FreeBSD 6.2 and other Linux variants
Message was edited by: Knobee to add version information
I am very annouying with this never ending clock problem...
My host is Dell Laptop with 2GHz Core 2 Duo running Windows XP. I am using VMWare Workstation 6.0.2.
My guest is Linux 220.127.116.11 with the latest vmware tools installed and running.
I have pretty much tried every trick I can find on how to fix the fast clock problem, but nothing seems to work. My linux guest is not useable because the clock is running about 2x or 3x real time.
Setting the host config with:
host.cpukHz = "2000000"
host.noTSC = "TRUE"
ptsc.noTSC = "TRUE"
didn't seem to help. I also need to add the kernel option noapic to linux with that config.
I have tried two different clock settings for linux: clock=pit notsc and clock=mptmr and no luck with either.
I set the kernel config to use 100Hz clock. Didn't help.
Now im just tinkering with different kernal options in the kernel config in hopes that disabling something will make it start working...
Anyone else have any luck with this problem?
After playing with the timing issues for a couple hours today I figured out that the guest OS runs perfectly as long as my laptop is on AC power when it boots. If the AC power goes away and comes back, it doesn't work without a reboot.
might want to try this to get the cpu freq
use that result for the first line of :
host.cpukHz = 1833000
host.noTSC = TRUE
ptsc.noTSC = TRUE
and insert this into the /etc/vmware/config
I don't believe you use quotes around the values
Enable the VMware TimeTracker logging:
timeTracker.statsIntercal="10" (for 10 sec. tracking intervall"
to the guests .vmx file (guest needs to be restarted) and post the entries from vmware.log (start with "TimeTrackerStats").
The issue with virtualization and (mostly) Linux guests is, that Linux (and other OS's, too) are using the PIT (Programmable Interrupt Timer) to count the timer ticks. Linux requests a timer interrupt in frequencies of 100 - 1000 Hz per OS instance + per (virtual) processor (n+1). One bad thing about that is, that this will consume ressources, even if the system itself is idle.
The other bad thing is that only the guest which actually owns the processor receives the interrupt, so many interrupts are lost (Lost Timer Tick). That's why the time of a virtualized machine would always run too slow, if there is no compensation.
Windows uses the PIT, too, and other different mechanisms/time sources which can even change if you install software, for example Apple's Quick Time.
As loosing these ticks happens on hardware, as well, there is a Lost Timer Tick correction algorithm within Linux to compensate this. This works well enough on pure hardware.
But there's a second compensation mechanism if you run it onVMware: VMware tracks the interrupts lost and sends them in a timely compressed manner to the guest later (in fact not all are send, some lost ticks needs to be deleted by the Vmware time management). That's the reason why the time doesn't run consistent and seems to "jump" sometimes.
So there are two mechanisms to keep the time accurate and that could lead to a clock running too fast (overcompensation). There is no way to slow it down with the VMware tools, yet, nor do they set the time back. Slowing down the clock is planned for a future release of the tools.
The suboptimal usage of the PIT has changed from Kernel 2.6.18 for 32 Bit / 2.6.21 64 Bit. In newer Kernels Linux uses a different lock source (TSC, Time Stamp Counter) where it can read the time directly (has not to count the ticks to generate the time) and without using an interrupts. Another advantage is that his time device can be read faster that the PIT.
We had the same problem (guest clock running too fast), and solved it using Steve-J's solution from above.
Our setup is as follows:
Host: Dell R200 server, CentOS 5.2, Kernel 2.6.18-92.1.18.el5PAE (SMP)
Guest: 2 processors (this is a definition in the vmx file), CentOS 4.6, Kernel 2.6.9-78.0.8.ELsmp
We just followed Steve-J's steps; on the host:
# cat /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_max_freq 2133000
And then use that number when adding these lines to the end of /etc/vmware/config :
host.cpukHz = 2133000 host.noTSC = "TRUE" ptsc.noTSC = "TRUE"
Then restart the vmware server:
service vmware restart
My FreeBSD-8.2 VM suddenly began exhibiting the same behaviour two days ago... In fact, I left work an hour early, because I looked at the KDE's clock inside the VM, instead of consulting that of the MacOS host...
For me the solution proposed on a FreeBSD forum helped:
I did this from command line and the clock began running normally. I then placed it into /etc/sysctl.conf, so that the setting survives reboots. I'm sure, Linux has a similar setting...