HighPerformanceCounter rounding

[Lutger]

nobody_ wrote:
>> 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...
> 
> You make timing sound even worse! :D
> What the article is talking about, as you just quoted, is that faulty(buggy) 
> hardware might not play nicely with multiple threads,
>  making it more safe to just limit it to one thread.(You make it sound like 
> those are two different problems :)
> Variable clock speed shouldn't matter. QPC was invented for just that 
> reason. It doesn't depent on only the cpu,
>  but if possible also on other hardware timers.

Yeah sorry about that, it's just that I had some timing bugs and they 
really annoyed me as I blamed my own code and wasted a lot of time on it.
There is a documented bug concerning a hardware timer in the mainboard, 
which has happened to me (single-core), so these are the two different 
problems I was talking about. I didn't know that QPC deals nicely with 
variable clock speeds too, didn't see that in the article, but it's good 
to know.
I guess my point was that if you find some weird timing things, it could 
be some hardware or timer 'bug' and your code could be fine...just in 
need of some workaround.