digitalmars.D.learn - HighPerformanceCounter rounding
- nobody_ (15/15) Oct 25 2006 foo being some random function
- Lutger (7/31) Oct 25 2006 It's probably because of the sleep function, this can be off by about 10...
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
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
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
Oct 25 2006
Thanks for the reply.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.It's probably because of the sleep function, this can be off by about 10 to 16 ms usually on windows, iirc.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?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
nobody_ wrote:Thanks for the reply.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.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.It's probably because of the sleep function, this can be off by about 10 to 16 ms usually on windows, iirc.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?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
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
nobody_ wrote: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.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.
Oct 26 2006
"nobody_" <spam spam.spam> 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