Phil Keslin (philk++at++cthulhu.engr.sgi.com)
Mon, 29 Mar 1999 10:50:22 -0800
The timer intervals are 10ms for non-realtime processes, and FASTHZ for
realtime. The value for FASTHZ is very system dependent. On Onyx2, its
about 800nsec and for Onyx, I believe its 21nsec.
> 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. The scheduling logic chose to awaken
non-realtime processes at the next clock tick (10msec) after the
interval has expired. Therefore, the process will awaken sometime
between 10msec and 20msec, depending upon when the timeout is scheduled.
There are no guarantees for non-realtime processes as to when the
process will actually run.
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.
> My nanosleep tests reproduced the same symptom.
> So it appears to be a basic kernel scheduling problem, not specific to sginap.
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.
We are currently looking at ways to obviate this problem. The first, as
Ran has already suggested, is to replace sginap with nanosleep and a
shorter interval. There are others as well. Our plan is to fix this
problem and to make sure that the fix works for all of our supported
platforms. In the interim, Ran's suggestion is a very good WAR for
realtime Performer processes. There really isn't one for those apps
which are not realtime.
- Phil
-- Phil Keslin <philk++at++engr.sgi.com>
This archive was generated by hypermail 2.0b2 on Mon Mar 29 1999 - 10:50:27 PST