www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - HighPerformanceCounter rounding

reply "nobody_" <spam spam.spam> writes:
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... :) 
Oct 25 2006
parent reply Lutger <lutger.blijdestijn gmail.com> writes:
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).
Oct 25 2006
parent reply Lutger <lutger.blijdestijn gmail.com> writes:
Lutger wrote:
 nobody_ wrote:

 
 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
Oct 25 2006
parent reply "nobody_" <spam spam.spam> writes:
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?
Oct 25 2006
parent reply Lutger <lutger.blijdestijn gmail.com> writes:
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.
Oct 25 2006
parent reply "nobody_" <spam spam.spam> writes:
 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...
Oct 26 2006
parent reply Lutger <lutger.blijdestijn gmail.com> writes:
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.
Oct 26 2006
parent "nobody_" <spam spam.spam> writes:
 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.
Oct 26 2006