NetNews Usenet Archive 1992 #20/NN_1992_20.iso/spool/comp/sys/sgi/13318

Text File | 1992-09-07 | 1.8 KB | 49 lines

Newsgroups: comp.sys.sgi
Path: sparky!uunet!snorkelwacker.mit.edu!thunder.mcrcim.mcgill.edu!root
From: [e-mail] (Thunder Root)
Subject: Real time features/problems under Irix 4.0.4
Message-ID: <[e-mail]>
Sender: [e-mail]
Nntp-Posting-Host: amerie.mcrcim.mcgill.edu
Organization: McGill Research Centre for Intelligent Machines
Date: Fri, 4 Sep 92 21:21:19 GMT
Lines: 38

Hi ...

We are using a Personal Iris 4D/35, running IRIX 4.0.4, to run a
real time control task at 50 Hz.

The real time task is created using sproc(), and given a non-degrading
process priority using schedctl(NDPRI, 0, NDPHIMAX). All memory in the
program is locked using plock(PROCLOCK), and stack space is locked as
well using mpin(). The real time event is generated by a VME bus
interrupt that is caught by our own driver, which then calls the
kernel routine pollwakeup() to wake up the real-time control task
which is waiting inside a select().

We can verify the performance of the task using an oscilloscope.
It runs fairly reliably (with a maximum jitter of 2 or 3 msec.) if I
edit files, run make, or list directories. However, serious delays
of around 200 msec. or so can be caused by things involving the
screen display -- such as moving and exposing windows. Scrolling
inside an xterm window will also cause such a delay (although
scrolling inside a winterm does not).

Our documentation on IRIX real-time talks about guaranteed process
dispatch times of 1 to 2 milliseconds for real time tasks. So ...

1. What really _is_ the worst case process dispatch time?

2. Is there anything we can do to improve ours? (short
   of booting the machine single user :-))

Thanks,

John Lloyd            Research Center for Intelligent Machines
[e-mail]   McGill University, Montreal
[phone]            Fax: [phone]