1

I'm trying to find a decent replacement on Windows for clock_gettime(CLOCK_MONOTONIC) and mach_absolute_time.

GetTickCount is annoying because it's deliberately biased: when the system resumes from suspend or hibernation, it seems Windows works out how long it was suspended (from motherboard) then adds that to the tick count to make it look like the tick carried on while the system was powered down.

QueryUnbiasedInterruptTime is friendlier: it's a simple, seemingly-reliable counter that just returns the time the system has been running since boot.

Now, I've experimented with QueryUnbiasedInterruptTime to see what happens when the computer enters each of: sleep, hybrid sleep, and hibernation. It appears that it's correctly updated so that it appears to be monotonic (ie, the system stashes it before hibernation and restores it so that applications aren't confused).

But, there's a note here on the Python dev pages (which, by the way, are a very helpful resource for time function reference!):

QueryUnbiasedInterruptTime() is not monotonic.

I presume someone did a test to determine that. Is that information accurate? If so, out of interest I wonder what you have to do to get the return value to go backwards.

Nicholas Wilson
  • 9,137
  • 1
  • 36
  • 79
  • 1
    My money is on them confusing monotonic with continuous. It is not, the update rate is unpredictable. Fire up Chrome and it suddenly starts incrementing with 1 msec precision. Getting apps to stop abusing timeBeginPeriod() is going to take a while. – Hans Passant Jan 14 '14 at 15:20
  • Hmm, that would be a bit surprising, since it's used correctly elsewhere in the article, which collects together a lot of helpful platform-specific information. – Nicholas Wilson Jan 14 '14 at 18:35

2 Answers2

2

QueryUnbiasedInterruptTime is guaranteed to be monotonic. The interrupt time has no skew added to it, so it always ticks forward although the rate may sometimes differ a little from the wall clock.

I couldn't find any good references for this in MSDN, but I'm now convinced that Hans is right in his comment, the CPython developers must have simply got confused.

Nicholas Wilson
  • 9,137
  • 1
  • 36
  • 79
0

The main problem with GetTickCount is the value being only 32 bits, i.e. it resets to zero every 50 days of uptime.

You probably need QueryPerformanceCounter API.

Soonts
  • 18,116
  • 9
  • 55
  • 116
  • 3
    Take another look at the question title. – Hans Passant Jan 14 '14 at 18:32
  • Take another look at the question 1st sentence. Both mach_absolute_time and clock_gettime(CLOCK_MONOTONIC) are high-resolution timers, while QueryUnbiasedInterruptTime only updates 64 times per second (unless some app mess with timeBeginPeriod API, but even in this case `QueryPerformanceCounter` is much more precise). – Soonts Jan 14 '14 at 20:00