> : 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."