Hi everybody,
I've got run out of ideas. But maybe I just have missed some vital information. If so, I would be pleased if someone could direct me to the right source. The same applies, if I posted to the wrong board.
I worked my way through all information I could find in the internet which is mainly the Document "Timekeeping in VMWare Virtual Machines" and all related KB articles. I also googled every keyword I could think of.
Problem: Time would run away on every linux guest-system, i.e. Some ubuntu-based with Kernel 2.6 or DSL (Damm-Smal-Linux) based with Kernel 2.4. I've not tried any of Windows
Host configuration:
uname: Linux flanders 2.6.19-default #3 SMP Fri Feb 2 16:49:46 CET 2007 i686 i686 i386 GNU/Linux (openSUSE 10.2)
VMware GSX Server for Linux (V. 3.0)
With timetracking enabled (as in the official document described) I see the following:
Oct 30 12:20:43: vmx| TimeTrackerStats behind by 101746881985 cycles (63751179 us); running at 100%; 0 stops, 4 giveups
Oct 30 12:20:43: vmx| TimeTrackerStats APIC0 633 ints, 63.30/sec, 63.30 avg, 100.01 req; 633 tot, 1000 req; 32 loprg, 32 rtry
Oct 30 12:20:43: vmx| TimeTrackerStats timer0 633 ints, 63.30/sec, 51.00 avg, 100.00 req; 1020 tot, 2000 req; 260 loprg, 296 rtry
...
Oct 30 11:20:53: vmx| TimeTrackerStats behind by 63729957189 cycles (39931050 us); running at 300%; 0 stops, 0 giveups
Oct 30 11:20:53: vmx| TimeTrackerStats APIC0 1268 ints, 126.76/sec, 111.11 avg, 00.03 req; 4445 tot, 4001 req; 0 loprg, 0 rtry
Oct 30 11:20:53: vmx| TimeTrackerStats timer0 1268 ints, 126.76/sec, 82.10 avg, 00.00 req; 4927 tot, 6000 req; 30 loprg, 42 rtry
Which leads me to the conslusion, that the tics are to coming to slow, so vmware moves from 100% to 300% which results in a way to fast running clock.
In the document there is mentioned a skript to gather information about the issue. The output would be:
---
Virtual Appliances LAMP Version 1.0.150 (Beta)
Linux lamp 2.6.20-16-server #2 SMP Thu Jun 7 20:26:23 UTC 2007 i686 GNU/Linux
Tue Oct 30 14:41:05 EDT 2007
Tue 30 Oct 2007 02:40:22 PM EDT -0.455766 seconds
Tue Oct 30 14:41:06 EDT 2007
CPU0
0: 23375 IO-APIC-edge timer
1: 86 IO-APIC-edge i8042
6: 2 IO-APIC-edge floppy
7: 0 IO-APIC-edge parport0
8: 6 IO-APIC-edge rtc
9: 0 IO-APIC-fasteoi acpi
12: 130 IO-APIC-edge i8042
16: 2465 IO-APIC-fasteoi ioc0
17: 124 IO-APIC-fasteoi vmxnet ether
NMI: 0
LOC: 23347
ERR: 0
MIS: 0
CPU0
0: 24379 IO-APIC-edge timer
1: 131 IO-APIC-edge i8042
6: 2 IO-APIC-edge floppy
7: 0 IO-APIC-edge parport0
8: 6 IO-APIC-edge rtc
9: 0 IO-APIC-fasteoi acpi
12: 130 IO-APIC-edge i8042
16: 2470 IO-APIC-fasteoi ioc0
17: 124 IO-APIC-fasteoi vmxnet ether
NMI: 0
LOC: 24351
ERR: 0
MIS: 0
Tue Oct 30 14:41:16 EDT 2007
Tue 30 Oct 2007 02:40:30 PM EDT -0.915836 seconds
Tue Oct 30 14:41:17 EDT 2007
---
I'm not really sure how to interpret this. The difference between both timervalues is 1004. This should be 1000 if I'm not completly wrong. The oputput of the date command to the hwclock differ 44 seconds at the first call and (10 seconds later) the difference growed to 47 seconds.
What I tried:
- clock=pit|pmtmr|tsc
- noapic nolapic nosmp
- host.cpuKHz, host.noTSC, ptsc.noTSC
- TimeTracker.catchupPercentage, TimeTracker.catchupIfBehindByUsec, TimeTracker.giveupIfBehindByUsec
All of these seem not to change anything at all.
Right now vmware-tools are not running because as I understand it would only set the time about every minute and mainly wouldn't change the clock back in time anyway.
Thanks for helping,
Björn Bores