This is the mail archive of the
cygwin-developers@cygwin.com
mailing list for the Cygwin project.
Re: sub msec sleep/timers
Brian Ford wrote:
>
> > You may want to check the effective resolution of such timers.
> > It's not because they measure time in 100ns units that they have
> > 100ns resolution.
> >
> Yes, I know.
>
> Waitable timers do seem to get tick rate accuracy in my tests so far on
> XP/2k/NT. On 98, I think the same is true, but scheduling accuracy in
> general seems to be all over the board. Have you seen this too?
What do you mean by "tick rate"?
The results are platform dependent and also depend in a non obvious
way on previous calls to timeBeginPeriod(), which is called by gettimeofday
and since recently by Xsleep.
> They might be available on 95 too. The MS documentation is not
> clear to me and I don't have any 95 boxes to test on.
>
> I have no idea yet what the max sleep time is with them. What do we need?
Sleep is OK. It goes up to 47 days or so. On 9x the multimedia timeR has
a short range, the multimedia time is OK.
> > For example the current timer measures time in ms > but has 10 ms
> > resolution on NT, more on 9X.
> >
> Really? I get much better response than that with nanosleep on NT and 98.
Sorry, I was imprecise. nanosleep now gets us 1 ms resolution but setitimer
is the one with 10 ms on NT, more on 9X. Do you get better values?
Also, there is posix requirement that if one calls Xsleep(d) or setitimer(d),
then the clock (gettimeofday) must advance by at least d during the interval.
Thus if the resolution of sleep/timers is improved, so must that of gettimeofday.
I am all for that, by the way.
Pierre