RE: a joint letter on low latency and Linux

[Magnus Danielson]

From: Linus Torvalds <[e-mail]>
Subject: RE: a joint letter on low latency and Linux 
Date: Thu, 29 Jun 2000 18:38:53 -0700 (PDT)

Linus, people of the list,

While this thread certainly contains a lot of enligthing material I
just wanted to remind you...

> > > Well, I personally would rather see that nobody ever needed RTlinux at
> > > all. I think hard realtime is a waste of time, myself, and 
> > 
> > The need for hard real-time comes when you have real-world requirements that
> > require absolute timing garantees with 100% reliability.
> 
> If you hadn't snipped the rest of the email, you'd have seen that I agree:
> _if_ there are truly hard guarantee requirements, RTLinux is the way to
> go.
> 
> The number of problems that really need RT-linux is practically zero for
> normal uses. This is, btw, why I've never applied the RTLinux patches to
> the standard kernel tree. My personal opinion is that the RTLinux patches
> should _not_ be available by default, so that only people who really need
> the functionality start using it. 
> 
> Having non-hard-RT users start using the RTLinux functionality would be a
> disaster, in my opinion. The programming-interfaces are much more
> cumbersome, and the ways of making the system lock up hard are many and
> varied. 
> 
> If you do a computer-controlled radiation-dose machine for treating
> patients, and the latency guarantees have to be in the sub-100ms range,
> THEN you should use RTLinux.
> 
> If you're doing just audio that needs approximately 1% fo the CPU
> resources, and you have to use hard-realtime, the system needs work. Using
> RTLinux is a way of saying "oh, we can't fix this properly@.

Actually, this really depends on what happends in that box besides the
application. If you can't make it work on an empty machine, then you
are correct. However, how do you intend to _ensure_ that something
works regardless of load?

My point is that there are a number of things that will not work
stable enougth and that doing the clever tricks migth be hard even for
a good programer. Many stuff can survive perfectly well without the
hard realtime support just as many transmission can survive without
hard bandwidth allocation. Actually, scheduling of tasks in a CPU
bears a lot of resemblance with the task of maintaining many streams
of traffic in communication systems. The ATM folks did never succseed
in solving it all, the IP people will not (but few have realized it).
Really, you will not solve it all in Linux either. However, you can
solve a hell of a lot of them.

You can make many, many things including videostreaming work rock
solid for most of the time using the service provided by the Linux
kernel today.

I firmly beleive that the only real tool to solve a problem with is to
understand your problem and the other tools you have to solve things
with. Now, we can not really solve the first thing, namely having
people understand what they do, but we could at least ensure that we
have them understand the tools that they have. What I really say is
that good documentation and good educational information is really
required and trying to say that you just have to do "The Right Thing"
or whatever is a very arrogant way of pushing the problem away.

I can understand that many of the top notch people do that. Also they
"know" (or think that they "know") what is "The Right Thing", but in
the long run you need to convey that so that others can see the
alternatives clearly and see which of the available methods really
matches their requirements.

The usage of things like RTlinux does not by automagic solve problems,
propper engineering does. However, propper engineering do requires
good understanding of how things stick together and as the Linux
kernel code grows it becomes harder for people to read up on that as
well as track all the wise things on lists like this list. Also, a
good engineering solution requires the appropriate tools, if you do
not have those tools you have to invent them or you really do
something more or less crappy or useless and hope that nobody
discovers this.

So, even if I do beleive that many things could be done without the
hard or loose realtime support in the kernel, I also see that there
are a few things which will require it. What I feel is lacking is
really a well distributed to view on how diffrent types of
scheduling/timing requirements on interaction and processes should
work and should be implemented. You could really defuse a lot of the
requests for RTlinux by improving the documentation and education on
the code that we have. Then, when you have this framework which people
go to, it should less scary to include the necessary parts for strict
real time as well.

No, source is _NOT_ a complete form of documentation, it is a very
valueble form of documentation though. Really, it documents the
implementation but not the overlying concept.

> NOTE: I'm fully aware of the fact that Linux needs improvment in this
> area. I've tried to explain that my beef with the low-latency patches has
> never been that I don't believe it is a worthy goal. It's just that I also
> firmly believe that there are right ways of doing this. Without ugly
> patches that add random stuff to random places.

Well, if it is a worthy goal (which I do tend to beleive) and if there
is a right way (which I also tend to beleive), who will engineer it?
Will you?

For you enjoyment, a list of things which did not solve all the things
it has been promised to solve:
ATM
IP
Switches
Routers
Cisco Routers
Ethernet
ISDN
Sonet/SDH
HDLC/PPP
Object Oriented programming: C++ etc.
Logic programming: Prolog etc.
Functional programming: ML etc.
Modeling languagues/graphical environments: UML, SDL etc.
ISO OSI layer divisioning
ISO's protocol
X25
Windows NT
WWW

and the list goes on.

Common fault: The ease by which one fools oneself that one has built a
system "that does it all". It's really like the fellows selling
magical elixirs that cures anything and generally improves you healt,
wealth etc.

Cheers,
Magnus