broken timer values workaround

Started by
3 comments, last by DeadXorAlive 17 years, 10 months ago
I use the timer from GLFW, which I guess on Windows is QueryPerformanceCounter although I'm not sure. Once in a while, it gives totally wrong values. After googling I suspect it is because i have AMD cool 'n quiet installed, which can change cpu frequency and thus mess with the timer. There are similar issues on Intel speedstep and dual-core processors: some random thread about this. I've found the RDTSC asm instruction which I could use with inline assembler, but I think it will suffer the same issues. Do you know a good workaround and what are the caveats? Should I use a different, less accurate timer or measure some average, and when the timestep deviates too much from it ignore it or something like that?
Advertisement
The general consensus is "call QueryPerformanceFrequency() often". This way you'll limit the problem.

Regards,
O.k. thanks, this is what I wanted to know.
The QueryPerformanceFrequency function retrieves the frequency of the high-resolution performance counter, if one exists. The frequency cannot change while the system is running.

So assuming the documentation isn't outdated, it's guaranteed that the return value from QueryPerformancefrequency doesn't change. Not even with Cool & Quiet or multicore systems.

However, the value returned from PerformanceCounter might jump forward or backward occasionally:
When computing deltas, the values should be clamped to ensure any bugs in the timing values do not cause crashes or unstable time-related computations. The clamp range should be from 0 (to prevent negative delta values) to some reasonable value based on your lowest expected framerate. Note: This clamping is likely to be useful in any case when doing debugging of your application, but be sure to keep it in mind if doing performance analysis or running the game in some unoptimized mode.
Thank you for the information. Reading the article and the thread I linked to better, it seems that QueryPerformanceCounter reads the actual frequency of the core with cool 'n quiet, while QueryPerformanceFrequency still gives the same (incorrect) value.
There is a hotfix for XP, haven't tried it but thought I would mentioned it here anyway. It is said Vista will fix this.

I will go for the clamping and try averaging if clamping doesn't work out.


This topic is closed to new replies.

Advertisement