Phil Keslin (philk++at++cthulhu.engr.sgi.com)
Tue, 30 Mar 1999 14:37:17 -0800
Again, the value for fasthz is system dependent. For example, my Onyx
give 1200 and another Onyx2 gives 1250.
> This is the default setting in the 6.5.2-distributed /var/sysgen/mtune/kernel file.
> So how did the 800nsec pop up?
> 21 nsec?? Is this a typo?
My description above was incorrect. Timer intervals are rounded to
fasthz. The resolution of the underlying clock (from which the
interrupts are delivered) has a higher frequency than fasthz. For Onyx
it is 21 nsec and I believe 800nsec on Onyx2.
> >
> > > Also when the time-slice is 1ms there is an extra slice of sleep. Thus you get
> > > 11 ms from sginap.
> >
> > The semantic is (and was supposed to have been) that you will sleep for
> > at least the time requested.
>
> Imagine sleep(1) returning after one minute :)
Anything is possible in a non-hard-realtime environment.
> > The scheduling logic chose to awaken
> > non-realtime processes at the next clock tick (10msec) after the
> > interval has expired.
>
> Then this is a definite change from pre 6.5 itimer logic.
>
> > For realtime processes, again the sleep will last at least the interval
> > requested, but the wakeup will occur at the next fasthz tick following
> > expiration.
> >
>
> Again, a change from pre 6.5 logic.
Yup!
> >
> > This is not a scheduling problem. The old behaviour (sleep for at most
> > the duration of the interval) was actually incorrect and Performer
> > depended upon that incorrectness.
>
> I suspect other programs out there depended on that 'incorrectness' as well.
That is why we are evaluating mods other than those that effect
Performer.
- Phil
-- Phil Keslin <philk++at++engr.sgi.com>
This archive was generated by hypermail 2.0b2 on Tue Mar 30 1999 - 14:37:29 PST