The TimeDX millisecond timer
test displays a screen similar to this:
Displayed at the top of the dialog
is the minimum timer resolution in milliseconds, this is the smallest interval
that the Multi-Media Extensions report available, if this is not 1 DMDX's
performance will be sub optimal. The High Performance Counter (HPC for short)
is accurate to the displayed frequency. On modern processors it effectively yields
a microsecond timer, if you have a system that provides a high performance
timer that has a lower frequency it is possible that it's use may in fact
be worse than DMDX version 1 can obtain when not using the HPC, as I've never
seen nor heard of one I'm not going to write about it's implications.
Click Start to start the Millisecond timer verification.
Displayed next to "Millisecond Timer" is the high performance timer's converted
value in milliseconds, to verify it's accuracy you will have to use a stop
watch and run the test for a long time. If "Automatic Update" has been unchecked clicking
Refresh (which doesn't work so well if windows is smoothly animating it's
windows) or Stop will update the list box with a track record of the latencies
between millisecond callbacks, otherwise they will be updated once a second
or so. On all machines tested so far these intervals are far from exactly
1.0ms, however the OS goes to extensive lengths to make sure there are 1000
of them in a second, so for most 1.1ms intervals there will be a similar number
of 0.9ms intervals and so forth. There appear to be two classes of machines
here, the good ones that have the majority of intervals in the 0.9, 1.0 and
1.1ms bracket and standard deviations of 0.30ms or less and the not so good machines that have most latencies in the
1.9 and 0.1ms bins with SDs over 0.70ms (all very old processors you're not
likey to see these days). I have no clue as to what puts a given machine into
a given class (the "Automatic Update" checkbox was an attempt to see if updating
the results was the cause) but these days you're not likely to see a poorly
performing machine. Needless to say RTs measured
on the good machines are going to be more accurate than the ones measured
on the later machines -- see DMDX's Input section for advanced measurement of these latencies' affects.
The Advanced Video
and Millisecond Timer test gathers
this same latency data, however the DirectX video system is active then as
opposed to the windows display in this test and machines that perform relatively
poorly with this test perform better there without the windows messaging overhead.
By the time the retrace tracking thread is activated in the Vertical
Retrace Sync Thread and you turn
on the Millisecond test as well the results move back in the direction of
this test, however they are still a bit better than indicated here, patently
windows messaging involves a higher overhead.
The Benchmark button determines how much overhead reading
the HPC invokes by polling the high performance timer as many times as it
can in a millisecond. The values on all systems I have tested so far are
surprisingly low, around 200 times per millisecond, perfectly fast enough
for DMDX's purposes but we're talking about machines that execute many, many,
millions of instructions per second. Originally I thought this was largely
because the high performance timer is a double precision floating point value
(64 bit) and in order to read it as milliseconds it must be divided by a constant,
but as the second part of the benchmark shows the arithmetic is no particular
burden (typically 1/30th of the HPC read), the overhead must either be in
reading the clock itself or the call to OS.
There are two times I
have seen the millisecond timer stuff not work, in TimeDX when this happens
the list box of latencies does not update. One was when the Explorer had
been open for a long while and a CD was in my CD Drive that Explorer does
not like and it was caught in an infinite loop. Once it had been terminated
with cntrl-alt-delete the millisecond timer started working again. This is
not a weird as it sounds, the millisecond code is part of the multi-media
stuff, the CD probably has an audio track and is therefore part of that subsystem.
The other time is after TimeDX crashes and you run it again.
Hopefully by the time you get the thing you won't be able to make it die,
however the nature of the Universe being what it is someone will. Basically
if the program does one of a number of verboten things it is summarily terminated
by the operating system, which is fine, except that if the millisecond timer
callback was being used it appears to get snarled on older operating systems.
Running TimeDX until the latency list box updates will fix the problem, at
most I have need to run TimeDX twice.
NOTE: Users of laptops may need to pay closer attention to
the use of the high performance timer. A Windows 2000 timer is derived from
the RDTSC instruction available on Pentium 5 and higher CPUs, it's count is
based upon CPU clock frequency, something that normally doesn't fluctuate
-- however a laptop can switch it's CPU clock for it's low power standby,
so some care needs to be taken to make sure the laptop isn't in any a low
power state. If I had a laptop I could offer some advice, I don't so I can't.