HighPerformanceCounter rounding

[Lutger]

nobody_ wrote:
> Thanks for the reply.
> 
>>> It's probably because of the sleep function, this can be off by about 10 
>>> to 16 ms usually on windows, iirc.
> 
> I think so too, except that the usleep is never off by more than 2ms here ;)
> My program will only be run on one computer, which makes it alot easier, but 
> I already decided to let my AD card determine the rate.
> 
>>> Beware that sometimes QueryPerformanceCounter, which 
>>> HighPerformanceCounter uses, can behave erratically on dualcore systems 
>>> and systems with variabele clock speeds (Intel's Speed Step, AMD's cool 
>>> 'n quiet).
> 
> I've been reading through the msdn:
> http://msdn.microsoft.com/library/default.asp?url=/library/en-us/directx9_c/Game_Timing_and_Multicore_Processors.asp
> As I read it QPC takes care of multicore etc. (I only care about winxp 
> directx9 :)
> Only if QPC determines that the RDTSC is a stable counter will it use that 
> counter.
> Otherwise it searches for a better source (mainboard counter chips etc).
> What I do miss is the QueryPerformanceFrequency to check the granularity or 
> did I just miss it somewhere?
> 

Unfortunatly QPC does not always play nice with multicore as said in 
that article: "While the QueryPerformanceCounter / 
QueryPerformanceFrequency API is intended to be multiprocessor aware, 
bugs in the BIOS or motherboard drivers may result in these routines 
returning different values as the thread moves from one processor to 
another. We recommend that all game timing be computed on a single 
thread, and that thread is set to stay running on a single processor 
through the SetThreadAffinityMask Windows API."

And then there is variable clock speed, buggy hardware. I sometimes have 
  leaps a few ms forward in time, seems to be a because of a defect in 
the southbridge. Timing bugs are not fun...

QueryPerformanceFrequency is only for checking counts per second, but 
granularity of QPC should be good, it just can have some overhead per call.