The HPET bug: What it is and what it isn't

I had a look at changes of the QPC API function when 1809 was released and compared it to previous versions. There is only a small difference and that's a nicely solved integer multiplication to unify the timestamp to 10 MHz for TSC (as QPC mode). My guess is that this implementation is actually faster by a few cycles, but I did not measure it.

These are parts of the code of QueryPerformanceCounter() for RS4 and prior on the left and RS5+ on the right. They don't show everything, but I apparently chose to screenshot only those lines of code, can't remember why.


You can also see here that both just rely on a call to RDTSCP, although there are multiple codepaths available for fencing on other platforms. This was on Intel Coffee Lake.

I also played around with their new way to figure out if there is any loss of precision due to the new QPC code. These are two measurements of 1 second each showing different calculation methods and their precision. Of course the integer multiplication is the fastest, although it's only precise to ~100 ns:


The additional latency shouldn't have anything to do with the QPC function itself. That said there is much more going on behind the scenes that could intervene with DPC latency in general. I think more details are needed to have a look at this. Screenshots from multiple TimerBench runs, DPC Latency checker and the full specs of the tested systems.

Edit: Sorry for the overshare, I wanted to post this stuff a while ago but never got around to it.

You're clearly a genius.

I've optimized my system to the max but I wanted to try the HPET off thing.

Is it going to help? I have a 9900k at 5ghz 4133 ram and a 2080 super overclocked.

What are your thoughts?

Hi. Great program but i think there is a bug with it.

I suspect the program also seems to count frametimes that happen when the 3D window is just activated and moving around the screen to place itself, causing wrong frametime output in the end result varying from 25 to 60+ms!

The whole time my frametimes are well below <1ms and steady 1000+fps.

So result are inaccurate anyway.

TimerBench 1.5

• Added awesome graphs to visualize the results of the Game Test. Available data: Frametimes, GPU Load, GPU Frequency, GPU Memory Frequency, CPU Load and CPU Max Frequency (the fastest core)
• Added the 99th Percentile average for frametimes to the result dialog. This shows the value that's better than 99% of all frametimes captured during the Game Test.
• Changed warmup period of Game Test to 3 seconds (instead of 5% of the collected data). To show all ignored values that are not part of the final result, the warmup period is shown as a red line in the graphs.
• Improved detection of the primary graphics cards
• Improved detection of SLI/Crossfire configurations. To keep things simple, the Game Test's sensor data will only capture the first card.
• Latest HWiNFO version 6.23 integrated
• Implemented with C++17, compiled with Visual Studio 2019 (staticly linked MFC und VC)

Download: TimerBench 1.5 (173 MB, Self-extracting Exe, CRC32: 34EC2A27)
Prerequisites: DirectX 11

tw. With this version I'm getting constant 'Could not read frametime data'.

[16:06:08] Demo window found!
[16:06:08] Injecting QPC hook DLL: C:\Users\Administrator\Desktop\Tools\TimerBench 1.5\QPCHook32.dll
[16:06:08] Starting PresentMon with session: TimerBench2128
[16:06:08] Starting PresentMon trace session
[16:06:41] Stopping PresentMon trace session
[16:06:42] PresentMon successfully stopped
[16:06:42] Parsing result file: C:\Users\Administrator\Desktop\Tools\TimerBench 1.5\Results\PresentMon.csv
[16:06:42] File not found or no access: C:\Users\Administrator\Desktop\Tools\TimerBench 1.5\Results\PresentMon.csv

Yeah, if the output file is opened with a tool, it is locked for further access. Copy it first to another location if you want to do some further analysis.

Please upload the screenshot to this forum. I can't read a single number on my mobile.

All results are pretty good. Enabling HPET does not hinder your performance at all, so if you want, you can leave it enabled.

If there would be a problem, it would look like this:


Check the frame times between the HPET and the TSC timer results, especially the 99th Percentile, which is a good measurement to see if your framerate was stable or had frequent stuttering (it means 99% of all frames you saw on your screen were better than x milliseconds):

Yours:

HPET: 5.16-5.57 ms
TSC: 5.36-5.55 ms

Flawed i9-10980XE:

HPET: 8.80 ms
TSC: 1.78 ms

That's a frametime about 5 times worse than without HPET enabled.

Dynamic Tick is something that can result in higher latencies because your system "ticks" only when it's needed, which can be slightly later than when it ticks at a fixed frequency (normally 64 times a second, sometimes even 1000 times a second). A tick is a wakeup for your OS to do certain things, like do some thread scheduling, increment some timers like your taskbar clock and so on.

You can disable it, but it might lead to higher power consumption, because your system has to do more work during idle.
On Windows 8 this feature was still buggy and led to a skewed taskbar clock. So it made sense to disable it back then. Today there shouldn't be any visible or even measureable advantage of a fixed tick frequency.