0

I am writing a fast and fairly accurate game timer for use on Windows. Microsoft recommends using QueryPerformanceCounter() for high-resolution timing, and it works as expected, but I am looking for alternatives that yield less execution overhead.

I did some Googling and found mention of QueryInterruptTime(), and its counterpart QueryInterruptTimePrecise() which should be more precise but incurs greater overhead. Their documentation (here and here) describes that they get the system interrupt time count to the nearest system tick (or 100ns unit). QueryInterruptTime() is starting to look good as a timing candidate, but there is very little documentation of its advantages and of its quirks.

And then there are KeQueryInterruptTime() and KeQueryInterruptTimePrecise(), and I have no idea how they differ from their "non-Ke" siblings.

Can anyone describe QueryInterruptTime() and KeQueryInterruptTime(), their differences, pros and cons, and compare them with the more ubiquitous QueryPerformanceCounter() please?

MathuSum Mut
  • 2,675
  • 2
  • 23
  • 56
  • Is such a thing actually a requirement? Most game code does not actually need to know the time "right now", but rather cares about what the time will be when the frame is actually rendered on screen. Thus your game actually cares about the timer advancing according to an idealized rate - which is going to provide the most consistent user experience - and the game loop then delivers frames to the screen at - as close to this rate - as possible - possibly using vsync. – Chris Becke Jul 26 '16 at 12:44
  • Yes that is true, I am simply enumerating the possible options that exist in order to try to find a QPC alternative that offers less overhead but is robust enough for use allow acceptable game timing. – MathuSum Mut Jul 26 '16 at 13:29

1 Answers1

2

QueryInterruptTime() and QueryInterruptTimePrecise() require Windows 10 / Server 2016 as minimum versions.

You must have read Acquiring high-resolution time stamps while reading the QueryPerformanceCounter() documentation. This clearly discloses the advantages and pitfalls of QueryPerformanceCounter(). The function only shows notable overhead on HPET and PM timer platforms because it requires a kernel transition on such platforms. More recent platforms do perform timekeeping and performance counter business using the CPUs Time Stamp Counter (TSC) with very little overhead.

If it is just about precise time, you may also look into GetSystemTimePreciseAsFileTime() . This function is supported from Windows 8 / Server 2012 (desktop only). However, it also uses the performance counter under the hood and therefore suffers from the same bottleneck in terms of overhead (HPET/PM timer).

The same applies for the function QueryInterruptTimePrecise().

The function KeQueryUnbiasedInterruptTime() can be used in kernel mode drivers and it can bridge sleep states accurately when compared to KeQueryInterruptTimePrecise(). Note: No kernel transition here but you'd have to do the transition elsewhere I suspect.

Unfortunately, there is no KeQueryUnbiasedInterruptTimePrecise().

Arno
  • 4,864
  • 3
  • 35
  • 60