Gettickcount and the rest...

[Fran]

It's very inacurate.

Is it still inaccurate even after calling Timebeginperiod(1) (which i can't thank clootie enough for) at the beginning of your app...i have found it returns exactly 1 - 2 ms afterwards if this is implemented.

So sleep(x) is affected by timebeginperiod? Well, i never thought it would be, so i never tried, maybe i will next time

[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

[Clootie]

There is however one major downside to using it. It's very inacurate. Sleep(1) will return 1-15ms later, rarely 1. With nothing else happening on the system, the average on my fast computer is 2-3ms, but as soon as something else is going on, it's 10-15ms.

As it's already been said: call timeBeginPeriod(1); and measure your accuracy again. You should be surprized!

[seiferalmasy]

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.

[Fran]

There is however one major downside to using it. It's very inacurate. Sleep(1) will return 1-15ms later, rarely 1. With nothing else happening on the system, the average on my fast computer is 2-3ms, but as soon as something else is going on, it's 10-15ms.

As it's already been said: call timeBeginPeriod(1); and measure your accuracy again. You should be surprized!

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.

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.

[I_am_root]

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.

[Fran]

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?

begin
 timebeginperiod(1);
 ilast_tick_count:=timegettime;

 while not iterminating do
 begin
  tick_count:=timegettime;
  if tick_count<>ilast_tick_count then
  begin
   inc&#40;itime,tick_count-ilast_tick_count&#41;;
   ilast_tick_count&#58;=tick_count;

   do_stuff!!!;
  end;

  inc&#40;this_is_a_counter&#41;;
  sleep&#40;1&#41;;
 end;

 timeendperiod&#40;1&#41;;
end;

This will call do_stuff every 2ms on average. If you replace timegettime by gettickcount, do_stuff will be called every 16ms on average.

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

[Robert Kosek]

I just found this recently, but it might help you. Check this post at Asphyre.net and it might help.

[seiferalmasy]

"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

[Fran]

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