Re: nanosleep & sginap

New Message Reply Date view Thread view Subject view Author view

Brian Furtaw (brian++at++hotsauce.clubfed.sgi.com)
Mon, 29 Mar 1999 14:24:21 -0500

Try raising the priority of the process which is missing its deadline or
restrict the processor it is running on so that it has no competetion in the
scheduling algorithm. What may be happening here is that the sginap number of
ticks is up but for whatever reason another process of higher priority is
waiting to run so it gets the CPU for the next 10ms.

To retrict a processor (be root):

mpadmin -r <cpu_number>
...then use runon or pfutil functions to run the process on the restricted CPU,

int pfuLockDownProc(int cpu);
int pfuPrioritizeProcs(int pri);
int pfuRunProcOn(int cpu);

...another programmatic interface is the REACT supplied sysmp(2) calls which
allow you to lockdown cpus and processes to cpus.

Brian

On Mar 29, 7:41pm, Moshe Nissim wrote:
> Subject: Re: nanosleep & sginap
> Ken Lindsay wrote:
>
> > i had done some fiddlin' a few weeks ago trying to get better resolution
> > than sginap provides, and so i tested nanosleep and usleep. my conclusion
> > was that their resolution (at least in the default setup in IRIX 6.5.1)
> > is 10 milliseconds, just like sginap. here is some sample data:
> >
> >
>
> It is not a "resolution" problem, but an extra time-slice.
> Time-slice is 10ms in non-priority processes, and 1 ms in realtime priority
processes.
> Also when the time-slice is 1ms there is an extra slice of sleep. Thus you
get
> 11 ms from sginap.
> My nanosleep tests reproduced the same symptom.
> So it appears to be a basic kernel scheduling problem, not specific to
sginap.
>
>
>
> --
> 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

-- 
o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o


Brian Furtaw  (brian++at++sgi.com)	
VisSim  Technical  Consultant
12200-G  Plum  Orchard  Drive  Office:(301)572-3293   Fax: (301)572-3280	
Silver Spring, Maryland 20904  OpenGL/Performer/ImageVision/OpenInventor

New Message Reply Date view Thread view Subject view Author view

This archive was generated by hypermail 2.0b2 on Mon Mar 29 1999 - 11:33:35 PST

This message has been cleansed for anti-spam protection. Replace '++at++' in any mail addresses with the '@' symbol.