high resolution timer

[Uwe]

Well not exactly what you are looking for, but Qwt has a class QwtSystemClock with a similar API as QTime ( not QTimer ! ) hiding the high precision time classes of the various platforms.

Uwe

[bob2oneil]

I have done a little bit of research on this subject, and concentrating on Windows only (as Linux time resolution is not problematic), I have tried the following solutions under Windows:

1. Waitable Timer
2. Multimedia Timer
3. Queued Timer
4. Windows "Select" via Winsock interface - requires a created but unbound socket

Of these four, the multimedia timer provides the highest accuracy. The other timer variants have very repeatable delays and small standard deviation, but
the values swing in 15 ms increments. For example, when specifying a 100ms delay to waitable or queued timers, the delay will be approximate 108 ms
to a high priority task. This delay value is also true for delay settings down to say 94ms, and then the delay swings to 93 ms for a full range of specifiations below 94 ms.
This magic 15 ms is consistent with the descriptions of the lack of accuracy of the GetSystemTimeAsFileTime() API, and descriptions of the 15 ms kernel task switching times.

I have used the QueryPerformance counter method, but there are various bugs associated with it, and my accessment is that it is good for elapsed time, but not necessarily for high time precision.
I am currently using it for high precision elapsed time in combination with a "leap forward" solution using GetTickCounts as discussed in the following URLs:

http://support.microsoft.com/kb/274323
http://support.microsoft.com/kb/895980

Since the QPC is essentially a free running counter, it has no ties to the actual time keeping on the workstation under Windows. A correlation of this value has to be made for my application,
and most solutions seem to suggest a differential approach, where an initial value is snapshotted, and then delays calculated from this initial snapshot.

I found a fairly comprehensive article on the problem and a proposed solution on a legacy MSDN article for reading highly precise time under Windows at the following URL. You will see that the issue
is fairly complex and has to account for a number of factors including detecting NTP time changes.

http://msdn.microsoft.com/en-us/maga...163996.aspx#S6

Hope this helps someone else attempting to do a similar thing.

Thanks to everyone's input