Re: KeQueryPerformanceCounter

Tech-Archive recommends: Repair Windows Errors & Optimize Windows Performance

Maybe the answer is that not everything will work in a VM
in exactly same way as on a real machine,
code running in a VM can be preempted in times when
it can not be preempted on a real machine. Also, 2 ms
may be too high resolution to demand from Hyper-V.
But this are certainly not what you expected to hear.

Regards,
--pa



PabloDP wrote:
KeQueryPerformanceCounter is unreliable on a VM configured with Win '03 SP2 x86 as the guest OS and Hyper-V (Win '08 x64). We followed the advice of this blog (though is for Win32):
http://blogs.msdn.com/tvoellm/archive/2008/06/05/negative-ping-times-in-windows-vm-s-whats-up.aspx

adding the /usepmtimer in the boot.ini hoping that was the problem. The problem persists and actually occurs with either the guest configured with one or two virtual processor (the system is a IA dualcore, i.e. two processors are seen by the host Win '08).

Here's the trouble: A kernel-mode driver gets an interrupt from our own source (comes from the APIC) which occurs every 2 mec. Once we get the tick we schedule a DPC. In it we check we query the performance counter of the processor to see how many times the processor has ticked since the last time we got a tick from that interrupt source. Knowing the frequency of the counter, you can calculate how long it took and use thsi to get stats (avg DPC time, etc.)

The flaw in this is that it assumes that KeQueryPerformanceCounter() is reliable; but it is not. We see massive gaps in between ticks..in the seconds!

This code runs just fine on *most* "bare metal" (non VM) systems. We did experience it go back in time in one particular system though (which sort of resembles the above blog).

Any ideas?

btw, there are other problems with the VM: normally only one ISR is handled in the DPC; however when running in the VM, we see several interrupts, up to dozens, queued up!

.