Brian Furtaw (brian++at++dingbat.clubfed.sgi.com)
Tue, 30 Mar 1999 06:22:39 -0500
The way the timers work has changed I think Jenny and a couple of others summed
up pretty well how they changed. To get the scoop on the system clocks
REALTIME, FASTHZ and CYCLECOUNTER read the man page on `clock_gettime'. Cycle
counter runs at the resolution of the free running hardware counter which on
the Origin2000 is 800 nanoseconds on Octane is 80 nanoseconds and on O2 is real
low like 24 nanoseconds or something.
You can use a call to syssgi to mmap the cycle counter (example code provided
in the man page) and avoid a system call. Don Burns also provided a very nice
class interface, thanks Don.
As far as the use of calls like sginap or nanosleep give the processes using
them realtime priorities so when they are ready to wake up they get run.
On Mar 30, 10:45am, Moshe Nissim wrote:
> Subject: Re: nanosleep & sginap
> Phil Keslin wrote:
>
> >
> > 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.
> >
>
> 'systune fasthz' on 6.5.2 gives 1000
> 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?
>
> >
> > > 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 :)
>
> > 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.
>
>
> >
> > 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.
>
>
> Bye,
> Moshe
>
> --
> Moshe Nissim, Orad Hi-Tec Systems
> Tel: (972) - 9 - 7676862 (ext. 579)
> Fax: (972) - 9 - 7676861
> Email: moshe++at++orad.co.il
>
>
>
> -----------------------------------------------------------------------
> List Archives, FAQ, FTP: http://www.sgi.com/software/performer/
> Submissions: info-performer++at++sgi.com
> Admin. requests: info-performer-request++at++sgi.com
>-- End of excerpt from Moshe Nissim
--
----oOOo---- ----oOOo---- ----oOOo---- ----oOOo----
Brian Furtaw (brian++at++sgi.com)
VisSim Technical Consultant Office:(301)572-3293 Fax: (301)872-3293
12200-G Plum Orchard Drive OpenGL/Performer/OpenInventor/ImageVision
Silver Spring, Maryland 20904 Optimizer/React/PCI Device Drivers
This archive was generated by hypermail 2.0b2 on Tue Mar 30 1999 - 04:13:40 PST