Some findings on Windows timer functions accuracy, that may benefit WinUAE

[Dr.Venom]

Hi Toni,

A somewhat long post coming up, but please bear with me as it contains relevant information for WinUAE when it comes to the reliability of timer functions in Windows.

While looking into this matter I found some interesting things about the (un)reliability of QueryPerformanceCounter and the High Precision Event Timer (HPET). I'll start with the bottom line conclusions and end with a suggestion for a possible solution for WinUAE (a suggestion since you'll know better).


Bottom line conclusions on the (un)reliability of the timer function in Windows

1. The HPET hardware timer is disabled by default in Windows 7 (and possibly 8), even if a user has it enabled in the BIOS!

Summarizing, apparently there where unexpected problems with the HPET implementation on motherboards a number of years ago, which apparently made Microsoft decide to disable the HPET timer alltogether on Windows 7. This even when you have a state of the art new motherboard with proper HPET implementation!

• A properly working HPET returns a 14Mhz value
• If it does not it's -not- using the HPET hardware timer of the motherboard, but some psuedo low resolution timer instead (it will return some 3Mhz something value probably).

Please read the following blog post Using HPET for a high-resolution timer on Windows, which has more details.

As shown in the blog, it's easily tested whether the HPET is really active by doing a query via QueryPerformanceFrequency. If it returns 14Mhz then it's enabled, if it's returning some value in the 3Mhz range then it's disabled. I'm using quite a new mainboard, an Asus P8Z77-V, running Windows 7 and guess what? The HPET is indeed disabled in Windows 7, even though I have set it to enabled in the BIOS.

How to enable the real HPET timer?
If your BIOS has HPET enabled, then you can enable HPET in Windows with a bcdedit command, and disable it with a different bcdedit command.

Enable use of HPET

bcdedit /set useplatformclock true

Disable use of HPET

bcdedit /deletevalue useplatformclock

You’ll need to reboot to see changes, because this is a boot-time option (hence the use of bcdedit to change it).

2. QueryPerformanceCounter may perform poorly or unexpectedly leap forward

Please see the following two pages by Microsoft, detailing the issues with QPC on some platforms / setups:

• Performance counter value may unexpectedly leap forward http://support.microsoft.com/kb/274323
• Programs that use the QueryPerformanceCounter function may perform poorly in Windows Server 2000, in Windows Server 2003, and in Windows XP
  http://support.microsoft.com/kb/895980

The first page describes that the hardware implementation of the High Precision Event Timer (HPET), which is the basis for QPC, is suffering from a design defect on some chipsets. It also lists a number of known chipsets to have this defect, so people may be able to determine for themselves. The second page describes that QPC may in some situations deliver unreliable timing when used on AMD dual core or Intel multi core systems running XP or older.

See also the following blog describing the poorly performing timing Beware of QueryPerformanceCounter() : http://www.virtualdub.org/blog/pivot/entry.php?id=106

Given this information, we now know that especially for some "older" systems the QPC method may perform poorly and why. My guess is that this may be causing some of the issues that people with older hardware setups may have with WinUAE's (low latency) vsync implementation.


3. Possible route to an improved timer implementation

I've been thinking how this could be addressed from the software side. I guess one of the possible routes is to create an automated implementation: If QPF does return a value of 14Mhz (HPET is really active) then use QPC. Else use the more robust TimeGetTime() routine as a "second best" method. Even though the latter "only" has a resolution of 1ms, I guess it may be multiple times better than using a broken QPC. Of course automated implementations may have their drawbacks, so possibly a manual configuration option would be more desirable?

When I look in my WinUAE log, while having HPET properly enabled as descibed previously, I see that its dividing the new found (correct) 14.32Mhz value by two. I'm not sure why that's done?

CLOCKFREQ: QPF 14.32MHz (7.16MHz, DIV=2)

In any case, hopefully this information about the timers and the finding about HPET is useful. Cheers!

[Toni Wilen]

Originally Posted by Dr.Venom

If QPF does return a value of 14Mhz (HPET is really active) then use QPC. Else use the more robust TimeGetTime() routine as a "second best" method. Even though the latter "only" has a resolution of 1ms, I guess it may be multiple times better than using a broken QPC. Of course automated implementations may have their drawbacks, so possibly a manual configuration option would be more desirable?

Technically good idea but in future there may be other hardware timer frequencies. Hardcoded values are bad.

Also I don't support broken hardware, buy a better PC is the correct choice!

There is also small real world reason, fastest possible + low latency vsync requires timer resolution that is much less than length of 1 scanline.

When I look in my WinUAE log, while having HPET properly enabled as descibed previously, I see that its dividing the new found (correct) 14.32Mhz value by two. I'm not sure why that's done?
In any case, hopefully this information about the timers and the finding about HPET is useful. Cheers!

It is divided to keep it smaller than 10MHz, it is used to prevent overflow if timer is very fast, it must not 32-bit overflow too quickly. (at least few frames)

[Dr.Venom]

Originally Posted by Toni Wilen

Technically good idea but in future there may be other hardware timer frequencies. Hardcoded values are bad.

Also I don't support broken hardware, buy a better PC is the correct choice!

Of course

There is also small real world reason, fastest possible + low latency vsync requires timer resolution that is much less than length of 1 scanline.

I see, didn't realise it needed that precision..

It is divided to keep it smaller than 10MHz, it is used to prevent overflow if timer is very fast, it must not 32-bit overflow too quickly. (at least few frames)

You're slashing my HPET in half!??

I assume the HPET should be working at full resolution in the 64-bit WinUAE then? It would be great if you could address that, as currently it does the same division by two in 2.6.1 64-bit.

Would that then also be the first -good- reason to start using the 64-bit version from now on then?

----------------------------------------------------------------------
WinUAE 2.6.1 (2013.06.19) 64-bit (6.1 Service Pack 1 [1]) 64-bit 9.6.3A09 8 10:15
[...]
Reserved: 0x000007FF3FEB0000-0x000007FFFFFB0000 (c0100000 3073M)
CLOCKFREQ: QPF 14.32MHz (7.16MHz, DIV=2)
----------------------------------------------------------------------

[Toni Wilen]

Originally Posted by Dr.Venom

I see, didn't realise it needed that precision..

It checks every few scanlines how big is the difference between emulated time and current time, if gap is big enough, some extra CPU time is emulated until times are back in sync.

I assume the HPET should be working at full resolution in the 64-bit WinUAE then? It would be great if you could address that, as currently it does the same division by two in 2.6.1 64-bit.

No, it would make no difference whatsoever, reading the timer takes longer than 1 time unit (on my PC reading timer twice back to back has 10 unit difference)

[Dr.Venom]

Originally Posted by Toni Wilen

It checks every few scanlines how big is the difference between emulated time and current time, if gap is big enough, some extra CPU time is emulated until times are back in sync.

No, it would make no difference whatsoever, reading the timer takes longer than 1 time unit (on my PC reading timer twice back to back has 10 unit difference)

I'm not sure if I understand.

Is it generally so that as long as the timer is accurate and has a resolution of at least a scanline, ~0.015Mhz, it's enough?