How reliable are QTimers on Windows?

**spud** · 23rd February 2009, 10:46

Originally Posted by stevey

I believe the smallest time you can respond to anyway on most OS's is 50ms. Anyone disagree with this?

You can absolutely except better precision than that. As someone suggested I would set up a separate thread which polls the time and sleeps. Do a google search for "high performance timer".
http://frank.mtsu.edu/~csjudy/direct...anceTimer.html

**Cruz** · 23rd February 2009, 11:55

Regarding the suggestion of using a seperate thread, why should I do that? Is a sleep based control more precise, than a timer based control? My guts say that it isn't, because you never now when a thread will be woken up again and it might have slept too long.

I think the trade off between having a faster timer and the complication plus windows dependency of the code is not worth it for me. I can live with 16 ms as long as the rhythm is steady. The most important criterion is that every iteration should take an equal amount of time.

So the question that hasn't been addressed yet is, how precise are the timings that I get from QTime? When it says 16 ms, has it really been 16 ms? Or something between 10 and 20?

**spud** · 23rd February 2009, 12:53

Originally Posted by Cruz

So the question that hasn't been addressed yet is, how precise are the timings that I get from QTime? When it says 16 ms, has it really been 16 ms? Or something between 10 and 20?

On XP+ between 10 and 20 ms. on NT between 0 and 50 ms, assuming the GUI thread isn't too busy.

**Cruz** · 3rd March 2009, 22:29

Hm, here it says that QTimer now uses the multimedia timer API on Win XP and it should have a 1 ms resolution. That sounds good actually. But then how come that my measurements in my OP report 16 ms instead of 12? Could it be that the gui thread takes that long to process events before it can fire the timer? Or is it because the answer from Qtime::restart() is not precise?

**seneca** · 3rd March 2009, 23:36

You should try to understand the difference between windows and a real time operation system, for example QNX. No matter how hard you try, an application will NEVER be able to answer or process any request exactly per millisecond:

Besides your application, many other applications and system processes are running at same time sharing all the same processor and memory, and the scheduler will assign time to them in a non-tranparent way (non-transparent for the application). There is absolutely no guarantee that your application will get any processing time at all between two of your ticks. This is something beyond the scope of Qt (or any other application framework).