On May 28, 2009, at 11:13 AM, Patrick Schlangen wrote:
Hi,
The "Enhanced Timer" section suggests that
QueryPerformanceCounter should really be constant frequency. I will
take another look at my code that uses it, and test it again.
the other pages state that the timer frequency changes along with
the CPU frequency in some cases.
As I understood it, QPC can use different timer sources on different
systems (Windows picks the one it thinks to be the best), and some
seem to be irreliable when the CPU frequency changes (e.g. because
of SpeedStep/Cool'n'Quiet).
The danger of Windows moving the process between CPUs shouldn't be a
major problem as it could be eliminated by binding the thread to a
CPU (with SetThreadAffinityMask), but the Cool'n'Quiet thing seems
to be what renders QueryPerformanceCounter useless.
The whole processor affinity thing seems like a big kluge to me. I
guess the ThreadManager could round robin assign affinities, but that
sort of defeats the OS scheduling algorithms, just to try and make
timers be reliable. I saw one mailing list thread where a guy created
a thread and assigned it an affinity, then used that thread as the
tick server. Callers needed to signal a condition, then acquire a lock
and wait on it. The server woke up, did the timer calculations, then
signaled the waiting thread that he was done. Nice idea, but at the
end the author said it "suffered from performance problems", which
wasn't too surprising.
After reading the links you sent, I still think the multimedia timer
(timeGetTime) is the best thing to use although using multimedia
libraries in a network client application feels kind of strange.
I have to agree with that. One of the pages I read was saying that
every Adobe Air application links against Winmm. I suspect that I know
why... :-)
- Rush
