> : Now wait a minute here. Read the paper before commenting.
> : They create a "real-time" thread under Linux. That does not
> : mean that it does anything, that the OS has real time support,
> : etc. There was nothing particularly new about what it did.
>
> Here's what they did: they took over control of interrupt disable/enable
> and dispatch. They run Linux as a thread and allow you to have 0 or more
> real time threads. If all you are doing is running Linux, it looked
> to me like there was minimal impact to the performance of the system.
>
> Real time threads run on the bare hardware, they have little
> integration with the OS, other than a pipe like communications device.
> The programming paradigm is you run two processes, one real time that
> gathers events and stuffs them in the "pipe", and one normal that reads
> events out of the pipe and does time _un_critical processing.
That's fine for one class of real-time problems, but it's not going
to help make the RealAudio player (raplayer) useable on Linux.
RealAudio only has to produce AM radio quality audio from a
28.8kbps input stream, yet I only have to move my mouse into
a new window to get audio drop-out. The RealAudio application,
together with all the support that it is getting from the kernel
in audio drivers, networking code etc., needs to run at a higher
priority than most of the other stuff that might be going on.
This is also a "real time problem", although a different one
from the "get the O/S out of my way" hard real time crowd.
How will Linux solve this type of problem?
> They can guarentee real time response of 10Khz, with less than 15 usec
> variation. That was with Linux running a
>
> tar f - /usr | (cd /newusr; tar xf -)
>
> a web browser, X, etc, etc. Good luck doing that on IRIX up. Maybe MP.
We can already do this on MP with User Level Interrupts.
As for UP, stay tuned :-) (Since this mailing list goes outside
of SGI, I'm not going to say any more.)
--
Nigel Gamble "Are we going to push the edge of the envelope, Brain?"
Silicon Graphics "No, Pinky, but we may get to the sticky part."
nigel@sgi.com
(415) 933-3109
|