Linux fine, windows **** ?

I believe the problem (under windows) is this:

  1. timeGetTime() is easy to call, but returns only milliseconds (which at 50 fps gives an error of up to 5%!) and takes a long time to execute.

  2. QueryPerformanceCounter() returns microsecond-or-better resolution, but is slightly harder to call (because you need to divide by the resolution) and will occasionally step forward in time by > 4 seconds. It is faster than timeGetTime(), but still takes a good two microseconds on a P-III 1 GHz.

  3. RDTSC is very fast (I measured 47 nanoseconds), and cycle accurate. However, it is hardest to call (you have to define a “naked” assembly function) and you have to find out the effective CPU speed from somewhere (system registry, or measuring it).

What I end up doing is using RDTSC, but using timeGetTime() to calibrate the RDTSC every so often. If I do this calibration every 100 frames, that 5% error has shrunk to 0.05%, which I can live with :slight_smile: The draw-back is that it takes some time for the calibration to warm up, and I have to take a wild guess at CPU speed before then based on spinning for 10-20 milliseconds and counting cycles (which gives a good 10% error up front, worst case).

I’ve never got that 4 secondes step forward. However I’ve read about it on MSDN.

I only call QueryPerformanceCounter() once per frame. So speed isn’t really important there. (0.000002 sec?)

I use RDTSC along with QueryPermanceCounter(). With two RDTSC, a sleep() of 100ms and two QueryPerfCounter() to get the elapsed time, I get a CPU frequency accuracy of about 0.05%. (with 1000ms of sleep, it’s 0.005%)
However I don’t have that 4 sec step foward bug, so…


yesterday, i tried Windows 2000 on my computer. So, i changed my drivers. And there, my programm didn’t hang anymore, but the framerate was less than before.

Was it a driver problem ?