Why QueryPerformanceCounter and GetTickCount does not keep in pace?

Question

The Problem is found under Windows XP when I want to write a function like GetTicketCount64 which does not exists on this platform. Here is my test code: ``` uint64_t GetTickCountEx() { #if _WIN32_WINNT > _WIN32_WINNT_WINXP return GetTickCount64(); #else // http://msdn.microsoft.com/en-us/library/windows/desktop/dn553408.aspx LARGE_INTEGER Frequency = {}; LARGE_INTEGER Counter = {}; BOOST_VERIFY(QueryPerformanceFrequency(&Frequency)); BOOST_VERIFY(QueryPerformanceCounter(&Counter)); return 1000 * Counter.QuadPart / Frequency.QuadPart; #endif } for (int i = 0; ++i < 1000; Sleep(30000)) { const auto utc = time(nullptr); // System time const auto xp = GetTickCount(); // API of Windows XP SP3 const auto ex = GetTickCountEx(); // Performance counter const auto diff = ex - xp; printf("%lld %I32u %I64u %I64u 
", utc, xp, ex, diff); } ``` I cannot understand the below result. From this article, reply from Angstrom seems not correct. Last column suggests that the difference of GTC and GPC is…

Accepted Answer

You cannot compare the two timing sources, they have drastically different implementations in PCs.

`GetTickCount()` is derived from the clock tick interrupt, a signal that's generated by the real-time clock. Traditionally a dedicated chip, originally the Motorola MC146818, nowadays integrated in the south-bridge. It has the kind of oscillator that was used in watches, crystal stabilized and usually running at 32768 Hertz. This oscillator keeps running when the machine power is turned off, running off a lithium battery or a super-capacitor.

So resolution is quite poor, but it is made very accurate with very good long-term stability by periodically resynchronizing the clock with time provided by a time server, most Windows machines use time.windows.com. Review GetSystemTimeAdjustment() for details.

`QueryPerformanceCounter()` uses a frequency source available in the chipset. Traditionally the 8053 counter running at 1193182 Hertz. Nowadays the HPET timer, the HAL (Hardware Abstraction Layer) allows a system integrator to pick any frequency source he's got available. Using the CPU clock is not unusual in cheaper designs.

So resolution is very high, but it is inaccurate and there is no mechanism to calibrate this timer. Being off by 800 ppm from the reported QPF is not unusual. This timer should only ever be used for short interval measurements, the kind that a profiler would use for example.

So no, using QueryPerformanceCounter() as an alternative for GetTickCount64() isn't a very good idea, unless you can live with the inaccuracy. Technically you can synthesize your own 64-bit counter, as long as you keep track of the value of GetTickCount() overflowing. You could, say, increment the course count when the previous value was negative and the new value is positive, indicating that it overflowed. The only requirement is that you sample GetTickCount() often enough to see the transition, at least once in 24 days.

Why QueryPerformanceCounter and GetTickCount does not keep in pace?

Solution

Problem

Related problems