High resolution timer for simulation ?

[newt]

Anybody know of a high res timer available under W2k/Winnt4 which has better accuracy than QueryPerformanceCounter (and not the multi-media timer either), or knows of a way to count the number of vertical retraces that the graphics has done since the last time it was queried ?

[Siwko]

In a true multitasking system such as nt, QueryPerformanceCounter is the best your going to get (I can pull about 5ms resolution). Due to the overhead of the function calls, the calculation down to a usable number (seconds), etc, you'll never get and perfectly accurate number under about 10ms.

Siwko

[JWillmott]

Ultimatly, Functions like QueryPerformanceCounter() use the rdtsc instruction on the CPU to find the number of clock ticks since the computer was booted. It's the most accurate way of measuring time you can get

--Jules

[IsaackRasmussen]

Is it true what Siwko says... does QueryPerformanceCounter really on get down to a 5ms gran?
I thought that it was allmost as precise as using RDTSC directly, which I do.

If it is, then this should absolutely be more than enough for you Newt.

Isaack

QueryPerformanceCounter gives microsecond
resolution on all Pentiums and up (where the
correct timer registers are available).
However, you can only use it to calculate
elapsed time; you can't use it as a "timer"
within Windows to schedule events in the
future.

Also, it calculates overall system time. If
the Windows scheduler switches you out and
something else runs for a while, that time
will count, too -- which is what you want in
real-time simulations like games, but can
throw you off if you're trying to figure out
the "accuracy" of it by counting cycles of a
known loop or something.

Under Windows, it's Really Hard (tm) to get
good real-time performance in scheduling
callbacks; multimedia timers are about as
good as it gets, and there's things you can't
do from in there, and they're still not very
accurate. Typically, the best you can do is
to call PeekMessage() in a tight loop and
just running as fast as you can, giving as
little time as you can to other processes
(which helps if you increase your priority).

[CGameProgrammer]

I always use timeGetTime() which is supposed to return elapsed time in milliseconds. Is it inaccurate? RDTSC returns the number of elapsed clock cycles, good for testing the speed of an algorithm, but its value is independent of the actual time elapsed; it would return the same value on a 450mhz processor as on a 1ghz processor. So why use QueryPerformanceCounter as a timer?

[Lev]

Of course milliseconds are too inaccurate!
Just imagine a simulation where you data is updated 200 times per second and you have a serous problem if you want to do exact calucations envolving elapsed time (you'll get 5 ms, but for 210 fps you'll still get 5 ms, ...)

Although I use linux, I use a rdtsc counter which gives a somewhat good resolution ( i calibrate the counter before I use it).

but sometimes mircoseconds are'nt enogh, then I guess winnt/2k is a bad choice. If you need even better resolution you'll have to take a realtime OS (can't name any but I believe some give you up to 0.01 microsecond resolution)

-Lev

[IsaackRasmussen]

Lev, you calibrate by calling CPUID, right?

QNX is a realtime OS,

Isaack

QueryPerformanceCounter() uses the timer
registers, but it is compensated for the CPU
clock speed. You're supposed to also call
QueryPerformanceFrequency() and divide your
measurement by that to get "seconds". The
typical frequency is just over 1 MHz,
resulting in slightly better than microsecond
resolution, which is good enough for all
applications that can live on Windows (given
that Windows interrupt and scheduling
latencies are pretty horrendous, at least in
the worst cases).

On Linux, you might be able to use the
setitimer() clock/timer, which uses the same
registers, or just read the registers
directly (in which case you need to calibrate).

On BeOS, you can call system_time(), which
uses the same registers, but normalizes to
microseconds -- also, the BeOS scheduler uses
this same clock for scheduling, and interrupt
and scheduling latencies are much better, so
for a smooth environment it can't be beat.
Yeah, and if you were using an AMIGA, ...
<sound of lunatic being dragged off into the
distance>