Subject: Re: Linux: the next step

From: [email-masked] (Larry McVoy)
Date: Mon, 12 Aug 1996 14:49:45 -0700

: > No doubt to make room for some paper on TCL scripts or something.  Feh.
: > Yeah, if you can make me a copy or convince the authors to send me one I'd
: > appreciate it.
: 
: 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.

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.

I thought the new work was the idea of *not* buggering up your entire OS
to support real time.  They give the real time guys ownership of the CPU
with minimal impact on the rest of the system.  And they had to do next
to nothing to make this work, they just use Unix for everything except
the lowest level of RT work.  I dunno, maybe I'm projecting some pipe
dream, but I think this is really cool work.   Points for orthogonal
thinking on their part.

---

From: [email-masked] (Nigel Gamble)
Date: Mon, 12 Aug 1996 15:59:04 -0700 (PDT)

> 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?

> 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."
[email-masked]
(415) 933-3109

---

From: Bob English <[email-masked]>
Date: Mon, 12 Aug 96 16:31:30 -0700

In message <[email-masked]> you write:
>to help make the RealAudio player (raplayer) useable on Linux...
>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...
>

With mirrors.  You run another copy of Linux on a high-priority RT
thread.  Full API, fast preemption, minimal performance and code impact.
You work on linux-slow and run rt apps on linux-fast.  You could even
reboot linux-slow without losing your audio signal :-).

--bob--

---

From: "David S. Miller" <[email-masked]>
Date: Tue, 13 Aug 1996 04:45:56 -0700

From: nigel@aa5b (Nigel Gamble)
   Date: Mon, 12 Aug 1996 15:59:04 -0700 (PDT)

I cannot wait to recompile all of my applications so that they can
take advantage of ULI...

The whole idea behind whatever approach linux will take to anything
(using clone() for threads under Linux is a good example) is that you
will not need to teach all of your "dumb" old programs (even ps!)
about these special processes and or things a process can do.

[email-masked]

'Ooohh.. "FreeBSD is faster over loopback, when compared to
Linux over the wire". Film at 11.' -Linus

---

From: [email-masked] (Nigel Gamble)
Date: Tue, 13 Aug 1996 08:36:35 -0700 (PDT)

> I cannot wait to recompile all of my applications so that they can

I think you missed my point.  The real time approach that Larry
described will only suit the hard real time programmers who
want only to get the O/S out of the way and program the bare
metal.  The real time application code will have to be custom
written and will get no support from Linux itself - you can't
call Linux system calls from one of these real time threads.
Forget POSIX real time APIs!

IRIX's ULI mechanism already provides a similar facility for
people who are willing to trade O/S support for performance,
(since you can't execute IRIX system calls from a ULI, either).

> about these special processes and or things a process can do.

The next release of IRIX will have real time support for user
applications, even on a UP, with guarantees sufficient for
digital media (audio and video).  You won't need to recompile
your application to take advantage of this environment.
We already know what we need to do to achieve this, and have
already implemented most of it.  Our approach is based on a
fully preemptible kernel, interrupts that have a thread context
that can block, and making sure that interrupts are never disabled
for more than 100us.

I'm still waiting to hear "whatever approach linux will take"
to solve this problem.

---

From: "Greg Chesson" <[email-masked]>
Date: Tue, 13 Aug 1996 09:45:44 -0700

The new real-time facilities in Irix (Nawaf's scheduler) are superior to what
has been available before in any Unix-like system that I know of.  There are
two areas of shortfall, but these are probably unavoidable given the design and
its operating environment:

	1. priority-based scheduling is often a poor substitute for deadline
	   scheduling, although it is useful for many rt applications.

	2. once a process gets scheduled via the rt facility, if it does any
	   system calls you get Irix system call performance.  Sometimes this
	   will be an issue (by limiting the number of syscalls and rt apps),
	   and other times it will not be so important.

I believe that efforts to incorporate hard real-time scheduling into a
full-function OS will satisfy the large majority of customers who have
real-time applications.  These customers do not want to run on the bare iron -
they want their real-time and they want their OS also.

The Linux-based hack that Larry described is indeed elegant - I had a look at
the paper.  However, if that hack were enough to support a wide range of
real-time applications I think system hacks would have implemented it a long
time ago.

g