Re: sub msec sleep/timers

[Brian Ford <ford at vss dot fsi dot com>]

Sorry for the delay.  I had some of my facts mixed up and was trying to
straighten them out.

On Fri, 19 Sep 2003, Pierre A. Humblet wrote:

> 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"?
>
Well, I guess that is a UNIX term that I am applying to Windows.
Experimental results so far:

an XP  box 1024 Hz
a  2k  box 1024 Hz
an NT4 box 1000 Hz

The 98 box was not reproducable enough to get a solid number, but it
appeared to be around the same.

So, you could sleep for any arbitrarily small time, and be assured that
you would wake up on the tick that immediately followed, not the one
after that as nanosleep currently does.  nanosleep now always effectively
adds 1 ms to the requested period.

> 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.
>
Multimedia timers, or WaitableTimers?  I have been digging through the MS
docs on WaitableTimers, and have not yet seen any explicit dependancy on
timeBeginPeriod calls.

> > 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.
>
Ok, I think I understand.  Cygwin doesn't yet use the multimedia timeR,
does it?  That was your proposed patch to setitimer and such, but you ran
into this problem on 9x?

> > > 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?
>
You mean with stock Cygwin?  What do you expect on XP?  I haven't measured
itimers yet.

> 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.
>
That's not entirely true.  For nanosleep, clock_gettime(CLOCK_REALTIME)
must advance by that much.

<rant>Why did they make a high precision, real time sleep call depend
upon the system clock resolution and adjustments?  Why not
CLOCK_HIGHRES?</rant>

I'm looking at Cygwin's gettimeofday now, but it looks like I may be stuck
between a (IMHO) bad spec and Windows.

-- 
Brian Ford
Senior Realtime Software Engineer
VITAL - Visual Simulation Systems
FlightSafety International
Phone: 314-551-8460
Fax:   314-551-8444