So sleep(x) is affected by timebeginperiod? Well, i never thought it would be, so i never tried, maybe i will next timeOriginally Posted by seiferalmasy
So sleep(x) is affected by timebeginperiod? Well, i never thought it would be, so i never tried, maybe i will next timeOriginally Posted by seiferalmasy
Yes I believe so...it relies on internal clock, and a dude from another site has done numerous tests and quotes "Not a system tried on yet where the accuracy goes below 1ms, 2 at the most.
It also affects normal timers too, like dxtimer and even threadedtimer. I had a MAJOR problem until clootie sorted it
As it's already been said: call timeBeginPeriod(1); and measure your accuracy again. You should be surprized!Originally Posted by Fran
There are only 10 types of people in this world; those who understand binary and those who don't.
someone should really publicise that fact alot more. Its not common knowledge and it really is very very important for the maintenence of timers, sleep and even game loops.
I certainly will, at one time i needed very high accuracy, and used some rather esoteric methods to achieve it. The only reason i never tried timebeginperiod is because the documentation says it's only for the multimedia timers, i never expected it to work on sleep.Originally Posted by Clootie
In any case, i'll be testing this within the week under some pretty large workloads and heavy thread usage. I'll post here the results with/without those 2 lines of code.
How do you get the best accuracy between 2 function calls(or whatever)? If you give an answer, please give it MultiPlatform(not dependent on Windows API calls). Please give some code. Thanks in advance!
Note : I use Windows+Linux with FreePascal.
Finally, my answer
Ok, so sleep by itself is quite precise, sleep(1) will sleep for 1ms to a bit more (normally more like 1.5, rarely 3 or over) depending on load, but... and what a big but... the measuring unit, gettickcount, is not precise.
Gettickcount has a resolution of 15-16ms, i think it's exact resolution is 1/64 of a second, or 15.625ms, so reading the time with gettickcount will give odd results. For example you'll take a reading of 1000, and the next one will be 1015 or 1016. That doesn't mean that if you sleep(1) you won't get control back at 1005, 1006, or whatever, but if you read gettickcount to check what time it is now, it will give you an imprecise measure (1000 until it's 1015 for example).
So what must be done is using timegettime instead. So far it seems to me the resolution is always 1ms, but the documentation (and earlier posts seem to confirm this) tell us that we must call timebeginperiod(1) prior to any reading and timeendperiod(1) post any reading, to ensure that such a precision will be available.
Allright, what does this mean in code?
This will call do_stuff every 2ms on average. If you replace timegettime by gettickcount, do_stuff will be called every 16ms on average.Code:begin timebeginperiod(1); ilast_tick_count:=timegettime; while not iterminating do begin tick_count:=timegettime; if tick_count<>ilast_tick_count then begin inc(itime,tick_count-ilast_tick_count); ilast_tick_count:=tick_count; do_stuff!!!; end; inc(this_is_a_counter); sleep(1); end; timeendperiod(1); end;
Note that in both cases this_is_a_counter will be identical however, since sleep works the same anyway.
Last note, the timebeginperiod and timeendperiod can be removed if using gettickcount since they are used to improve the resolution of the reading of the counter read by timegettime, not the internal windows counter... or so i believe. Sleep does not seem to be affected by that command whatsoever.
Hope that helps someone, i pulled many hairs trying to figure out where the missing time was when using gettickcount. Stupid gettickcount, i'll never use you again!!!!!! EVER!!!!!!
ps: i think the resolution of gettickcount depends on the machine and or the os, so it may be different for you than for me.... sigh....
I just found this recently, but it might help you. Check this post at Asphyre.net and it might help.
"Sleep does not seem to be affected by that command whatsoever"
Apperently it does. On my computer Gettickcount is 1 ms when timebeginperiod(1) is called. And one guy who did full study saus sleep goes to 2ms accuracy at the least with sleep
Well, i stand corrected then. However, i can assure you that gettickcount will not have 1ms accuracy on all windows computers, and will have ~16ms accuracy on at least some, if not many. So if you must have ~2ms accuracy, timegettime + timebegin(end)period(1) should be used, but if you don't mind getting 16ms accuracy on at least some computers, gettickcount can be used.Originally Posted by seiferalmasy
Bookmarks