foo being some random function

foo took: 14896947 microseconds
foo took: 14896 milliseconds
foo took: 14 seconds

Simple rounding :)

How accurate are these readings on a windows XP machine? They seem pretty accurate (except for the simple rounding).

I tested the following

 c.start();
 std.c.time.usleep(1000001);
 c.stop();

usleep took: 999789
usleep took: 999
usleep took: 0

It isn't a big difference, but still... :)

nobody_ wrote:
> foo being some random function
> 
> foo took: 14896947 microseconds
> foo took: 14896 milliseconds
> foo took: 14 seconds
> 
> Simple rounding :)
> 
> How accurate are these readings on a windows XP machine?
> They seem pretty accurate (except for the simple rounding).
> 
> I tested the following
> 
>  c.start();
>  std.c.time.usleep(1000001);
>  c.stop();
> 
> usleep took: 999789
> usleep took: 999
> usleep took: 0
> 
> It isn't a big difference, but still... :) 
> 
> 

It's probably because of the sleep function, this can be off by about 10 to 16 ms usually on windows, iirc.

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).

Lutger wrote:
> nobody_ wrote:
<snip>
> 
> It's probably because of the sleep function, this can be off by about 10 to 16 ms usually on windows, iirc.
> 
> 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).

Some more information, including how to set the granularity of sleep to 1 ms (second link):
http://blogs.msdn.com/oldnewthing/archive/2005/09/02/459952.aspx
http://www.geisswerks.com/ryan/FAQS/timing.html

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?

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.

> 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.

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

Knowing the frequency does let you know whether your cpu is being used or
maybe something else.
I think I saw the function in the source code, so I could probably just call
it somehow.

I hope this post doesn't sound to allknowing, as I just read 2 articles :D and just needed the functions for a single computer...

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.

> 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.

Thanks for all the replies :)
I'll keep it in mind.