QueryPerformanceCounter in Windows jumps 20 minutes back

[robertvazan]

Apparently VirtualBox uses standard HPET frequency of 3.579Mhz, which overflows lower 32 bits of the 64-bit QueryPerformanceCounter value every 20 minutes. VirtualBox sometimes doesn't increment the upper 32 bits when the lower 32 bits overflow, which makes QueryPerformanceCounter jump back by 20 minutes.

This behavior breaks software that relies on QueryPerformanceCounter, sometimes in severe ways. I've observed 3d party server software freezing for 20 minutes, because it assumes QueryPerformanceCounter is monotonic.

Switching HPET on or off in VM configuration doesn't make any difference.

[WBaron]

+1

very important for me too. This cannot be difficult to fix, so please fix it as fast as you can!

[Klaus Espenlaub]

This doesn't add up (and claims that things can't be difficult to fix are not helping at all, if someone wants to help with such mysteries then at least attaching the VBox.log is required).

HPET is definitely disabled when one disables it in the VM config. Either way, it would be ticking at a rate of either 100MHz or 14.31818MHz. So what your information proves indirectly is that Windows doesn't use HPET as the time source for QueryPerformanceCounter.

I don't understand what information source you have when you made the claim that HPET usually runs at 3.579MHz, because that's not true. 3.579545MHz is the typical rate of the ACPI (sometimes also called PM) timer. This is a 32 bit timer, and thus it's totally normal that it overflows every 20 minutes.

There is no "monotonically increasing" (or that it uses the full 64 bit range) guarantee in Microsoft's documentation of QueryPerformanceCounter, so it's all up to your code to make sense out of it. I doubt that Microsoft makes an attempt at extending the ACPI timer to 64 bits in software, because that is very tricky and expensive (there is an interrupt when the timer wraps around, but that doesn't help as there is some IRQ delivery latency, which means if you're unlucky then the OS doesn't yet know that the wraparound happened, and this would be corrected a little later, resulting in totally weird readings).