kvm windows xp guest time skew

peril

Renowned Member
Oct 6, 2009
50
2
73
Newark, DE USA
Hello,

I'm wrinting this from my rdp connected kvm instance that is losing time to the order of minutes / 15 minutes - while I watch fantasy football on yahoo. (Not sure what I missed but ...)

what can I do to help reduce clock skew?

AMD 64 - win32 xp pro sp3 guest,

I decided to just watch the clock in windows - spooky - the ticker is about 2-3 seconds / tick (and it varies according to the workloads (it seems)).

Any ideas? (I have no idea how to set windows boot arguments like notsc - but there has to be something .

--Adrian
 
This is ugly - there isn't anything that jumps out except running ntp (or something similar) frequently on the guest.

Any other strategies? (Guess it's not too bad to run from a network side if it's hitting local time servers. )
 
thank you - since this is desktop workload - I just started synching the vm's to a local time server every 10 minutes or so - doesn't seem to have any problems with stability of the base os.

thank you.
 
thank you - since this is desktop workload - I just started synching the vm's to a local time server every 10 minutes or so - doesn't seem to have any problems with stability of the base os.

thank you.


Seems to be a bigger if then else condition...
We just started the machine 1.4b2 on Dell Intel Core Duo (strange buggy BIOS on that one by the way) and removed the -td-rtc-hack.
It "works" now even the Intel strongly drifts.

One thing we don't understand up to now is, why the patch did not fix
our PhenomII-X4-Platform, too (we ran 1.4b2 there, too). Maybe it depends on a different BIOS setting or something is different on AMD(CPU/Chipset/..) which prevents the patch to be successfull.

JP
 
Shucks - wish I would have been onboard prior to the 1.4 release - I started there. It's ok - for desktop workload it's fine. It's mostly irritating on windows. It's not so noticeable on Linux.
 
Shucks - wish I would have been onboard prior to the 1.4 release - I started there. It's ok - for desktop workload it's fine. It's mostly irritating on windows. It's not so noticeable on Linux.

You're running on Intel Platform?
The freezing is very extreme here on MSI/AM3-PhenomII-X4. There is no software solution (I know) to compensate if a second in the machine simply takes 3, 10 or more seconds in realtime. Even if I sync every second, this will only happen every 10 secs in realtime :-(.
Only for windows, yes but including Vista Enterprise...which should behave
different up to my understanding of the things.

JP
 
So I tried this - and it seemed to help (although not sure yet) - in the bios - I turned off the HPET timer. The clock seems better -and none of the windows vm's have freaked out since ....
 
I'm having clock skew issues in 1.4b2 in Windows Server 2003 and 2008, both SMP and single-socket kvm configs (if that matters), on the following hardware:

Dual Xeon 5320 (1.86ghz)
Speedstep OFF
12GB DDR FB-DIMM
 
Hrm, I guess I spoke too soon. I've changed config on all machines (2003/2008 servers, mix of 32 and 64 bit) to 1 socket / 1 core, and clock skew issues are gone.

Too bad! Now I have tons of idle cores just waiting to be used :)
 
man - that is good to know - I'm building a SOHO vdi with wolfdale e3xxx dual core and will see if I can get windows to behave better on that than the amd. The amd gets unhappy after anything that is particularily interrrupt intensive - high io /(disk or net) high cpu - but if if just chugs along doing nothing - it's pretty good.
 
Hrm... That was the wrong way to word it. What I meat to say:

I really wish these VMs could use more than 1 of my cores each!

We tried Windows2008R2. As soon as some application switches to
high resolution timing (SAP, Quicktime, Labview..) the time stalls.

We'll probably have to find access to one of the core developers of KVM regarding the lost timer interrupts on AMDs when running Windows
in high resolution time:-((.

I was thinking about how the fix was done: If I've got a sheduling of 1ms and get interrupts at 100us, I'll have too loose
Interrupts because interrupts are not countable, no qhestion it depends on load. I would have to count them in KVM and
send them out to the virtual machine when it's active.
Is it usefull to switch the Debian to higher sheduling rate (and increase the overhead but get it work for first)?
 
Last edited:
on the intel wolfdale setup - (dual core xeon 3xxx) - no noticiable time drift after 48 hours - so it doesn't appear as noticable.

--Adrian
 
on the intel wolfdale setup - (dual core xeon 3xxx) - no noticiable time drift after 48 hours - so it doesn't appear as noticable.

--Adrian

Do you use one of the applications which switch to higher resolution ticks?
SAP, Quicktime, Labview (or others I don't know up to now?).

It's like day and night. We doublicated the same machine and it behaves different as soon as one of those apps (Labview) is running. There is
one or the other second missing some time, but nothing which can't be compensated via NTP in one case and a fully unusable machine in the other.

VMWare has had the same issues. For most machines the increased timer rate of Kernel 2.6 fixed it.
I think its not the end of the story for them, too. We'll upgrade to PVE1.4 tomorrow, maybe things changed from 1.4b2.

http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=892
 
Last edited:
well - I'm not sure about how to tell if it switched to the high resolution timer - but I was running windows media playing running 720p to a small small window (and it didn't skew thru that.)

is there a debug setup or something where I could probe the clock or somthing ?

(A clock skew test suite perhaps?)
 
well - I'm not sure about how to tell if it switched to the high resolution timer - but I was running windows media playing running 720p to a small small window (and it didn't skew thru that.)

is there a debug setup or something where I could probe the clock or somthing ?

(A clock skew test suite perhaps?)

The mechanism is following: Windows f.e. XP starts with 30/15 ms resolution but any application may ask to increase that precision. The
highest requirement is taken furthermore...no way to decrease.

I don't know if this is enough for a test since I currently don't have a VM-Host anymore (we're updating to 1.4 and are changing the RAID
level from 5 to 10 and decouple host and VMs, hope this helps

to decrease IO-Load) :-(.

The WinXP I'm writing this from (physical machine) offers a range of 1...15ms and has got 0.977ms(!?) selected. Don't know which application called for higher resolution. There is a tool from Sysinternals (now Microsoft).

http://technet.microsoft.com/en-us/sysinternals/bb897568.aspx

If I could do it, I would reconfigure the hosts Kernel to 2 kHz to see
what happens, but I think to remember the pre-historic timer can't do better than 1ms and was one of the reasons to add other timers.

---

Jep, should really detect the problem...at least our VMWare machines run on 15ms timebase.
Should be the same when running XP on KVM/PVE.


http://www.eukhost.com/forums/f31/kernel-timer-resolution-increaser-5495/
 
Last edited:
I know this is quite an old thread.

An extract from the Red Hat / KVM docs found at:

http://docs.redhat.com/docs/en-US/R...rtualization-KVM_guest_timing_management.html

Using the Real-Time Clock with Windows Server 2003 and Windows XP guests

Windows uses the both the Real-Time Clock (RTC) and the Time Stamp Counter (TSC). For Windows guests the Real-Time Clock can be used instead of the TSC for all time sources which resolves guest timing issues.
To enable the Real-Time Clock for the PMTIMER clock source (the PMTIMER usually uses the TSC) add the following line to the Windows boot settings. Windows boot settings are stored in the boot.ini file. Add the following line to the boot.ini file:
/use pmtimer
For more information on Windows boot settings and the pmtimer option, refer to Available switch options for the Windows XP and the Windows Server 2003 Boot.ini files.


I haven't tested this currently but am going to in the next few days...