English Amiga Board


Go Back   English Amiga Board > Support > support.WinUAE

 
 
Thread Tools
Old 13 November 2013, 12:02   #1
Dr.Venom
Registered User
 
Join Date: Jul 2008
Location: Netherlands
Posts: 384
Some findings on Windows timer functions accuracy, that may benefit WinUAE

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.

Quote:
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: 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?
Quote:
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!
Dr.Venom is offline  
AdSense AdSense  
Old 13 November 2013, 13:11   #2
Toni Wilen
WinUAE developer
 
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 43
Posts: 21,362
Quote:
Originally Posted by Dr.Venom View Post
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.

Quote:
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)
Toni Wilen is online now  
Old 13 November 2013, 15:03   #3
Dr.Venom
Registered User
 
Join Date: Jul 2008
Location: Netherlands
Posts: 384
Quote:
Originally Posted by Toni Wilen View Post
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

Quote:
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..

Quote:
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)
----------------------------------------------------------------------
Dr.Venom is offline  
Old 13 November 2013, 17:25   #4
Toni Wilen
WinUAE developer
 
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 43
Posts: 21,362
Quote:
Originally Posted by Dr.Venom View Post
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.

Quote:
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)
Toni Wilen is online now  
Old 14 November 2013, 10:35   #5
Dr.Venom
Registered User
 
Join Date: Jul 2008
Location: Netherlands
Posts: 384
Quote:
Originally Posted by Toni Wilen View Post
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?
Dr.Venom is offline  
AdSense AdSense  
 


Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)
 
Thread Tools

Similar Threads
Thread Thread Starter Forum Replies Last Post
Memwatch functions in Action Replay III don't work in WinUAE Galahad/FLT support.WinUAE 12 11 May 2014 13:42
Benefit of 3.9 roms? desantii support.Hardware 38 09 October 2013 08:36
[WinUAE/A500] CIA A - Timer A INT2 problem leoha Coders. Asm / Hardware 2 22 October 2012 10:18
Lost F key Functions on WINuae startup breadbaker support.WinUAE 8 06 December 2005 20:09
WinUAE blitter <-> bitplane DMA timing accuracy? Photon Coders. General 1 24 November 2004 18:06

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +2. The time now is 07:04.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2018, vBulletin Solutions Inc.
Page generated in 0.06221 seconds with 13 queries