QueryPerformanceFrequency() is documented as not changing while the system
is running. If that’s true it can only really indicate the design speed of
the CPU, which appears correct for the CPU specified in this test.
Since it seems BIOSes these days throttle back the CPU, it does not sound
unreasonable that the cycle counter is running slow.
It seems the obvious test is to determine what the actual CPU clock speed is
during this test. If it is being clocked at ~10% of the rated speed on
average during this progam execution, then the counter is being read
correctly, and there is no problem.
In fact it would be surprising to observe anything else unless the actual
clock speed is fixed at the design speed (which may be a setup option which
could work around the issue for the time being).
The various documents cited so far suggest that as a cycle counter QPC can
be useful (if used with care) but it is not much use for any real time
timing.
I think the logic is that if you want to time items for external purposes,
then you should use timing linked to the interface. e.g. if your external
interface is video, then the actual frame rate is the finest resolution you
need because what you do in between frames is irrelevant. If your external
interface is audio, you should use the audio sample rate (or some
subdivision based on blocks of samples) for the same reason. Or whatever the
interface is. These timings must be known to the program since it is
interfacing to them.
But it is a major nuisance, and will mean rewriting some of my library code
for new projects!
Mike
----- Original Message -----
From: xxxxx@osr.com
To: Windows System Software Devs Interest List
Sent: Thursday, September 02, 2010 4:13 PM
Subject: RE:[ntdev] Interesting issue with (Ke)QueryPerformanceCounter
You’re right… that IS a known bug. But Gianluca is reporting here isn’t
that the time being returned is ragged, highly variable, or off “a
little”… he’s reporting that it’s off by almost A FACTOR OF MAGNITUDE.
I’m having trouble believing out of order execution, or reading the TSC on
two different processors which are not kept in sync, could be to blame for
THAT level of error. Or, do you have a scenario in mind that would explain
this.
This finding is really some pretty scary stuff, at least in my mind.
Peter
OSR
NTDEV is sponsored by OSR
For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars
To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer