Re: a joint letter on low latency and Linux

[Paul Barton-Davis]

Larry McVoy writes:

>I'm coming into this a little late but here's my take on all of this.
>I have a little background on this, I was asked to support this letter
>by using LMbench to "show" that there were no problems with the Ingo
>patches and declined.  I felt that what I was asked to do was misleading
>and I didn't agree with what was in the letter.

One clarification here. Benno Senoner asked Larry about this, and it
was not part of the process of gathering support for the letter. I was
actually unhappy that Benno had asked Larry to do this. Not because I
dislike Larry, but I considered it to be inappropriate at that
time. So be it.

>Paul and the others in favor of the low latency fixes are fond of pointing
>out that they must be good because this is how IRIX and BeOS solve the
>problem.  That's never a good reason to do anything - fortunately for
>all of us, Linus evaluates things on their technical merits.  And "IRIX
>does it" has no technical merit whatsoever.

This is a real misrepresentation of my point about BeOS (I know
nothing about IRIX). To talk about the way the BeOS people do things
as if its automatically a bunch of expeditious junk design is really
unfair to them. If you want to talk about what specifically is wrong
with the BeOS or IRIX approach to offering 1-2ms worst-case latencies,
I have no problem with that. I know that you are intimately familiar
with the IRIX case, and I don't doubt the reasons for you feeling as
you do about the work there. But IRIX, as little as I understand it,
strove for something quite different that we are talking about. I have
no interest in making Linux fully preemptible (actually, it would be
more accurate to say that I have opinion one way or the other). I
don't see it as the necessary end-point of an attempt to get the worst
case latencies down to the 1-5ms range.

>I and others have pointed out that if you need hard real time then
>what you do is use RT Linux and you can get exactly what you need.
>I've heard two arguments against this:

You're shooting at the wrong target here. We don't want hard real
time, at least certainly not in any sense that RTLinux defines it. 

Its quite easy, well relatively easy, to establish the worst case
latency in the current kernel if you know the hardware on which it
runs (and the drivers it has loaded). I don't believe that the kernel
contains any non-deterministic algorithms that would affect this
number, though I may very well be wrong about that.

All we "need" is to lower this upper bound to, say, 5ms. Thats not
hard real-time in any real sense. Anyone who *was* doing hard real
time on such a kernel would be crazy. 

>a) ``Other operating systems offer "soft realtime" and we don't want to
>   port our code from that to the RT Linux model.''  Translation:
>   ``other operating systems have made poor design decisions, let's try
>   and pressure Linus into doing the same thing with Linux.''  That's a

Larry, that is a very unfair characterization, just as I said
above. If you want to quote the "other OS" argument, restrict it to
BeOS and IRIX, and explain what the poor design decisions are. I
haven't seen anyone on this list or elsewhere explain why BeOS is
"poorly designed". In fact, I've seen several different areas
voicing interest in adopting some of their ideas.

>   In my opinion, it is better to do the right thing, wait until Linux is
>   the market leader, and then laugh at the screwed up systems that made
>   the wrong choices.  

No doubt about that.

>b) ``If we take the RT Linux path then Linus will never add the low latency
>   features we want.''

I think it would be more fair to assign quotations like this to the
people who made them. This argument is not present in the letter, and
nobody on that list except one person is known to support this
reasoning. It is not fair to respond to this letter by quoting
semi-private email with one of the signees.

For the record, I don't agree with this argument. I think RTLinux is
a great piece of work that provides *way* more performance than we
need, and requires a substantial amount of work for us to use; in
contrast, Ingo's LL patches converted 2.2.10 into an excellent basis
for the kinds of applications we are working on, and those
applications would also run (less reliably) on a non-LL-patched
version of all other versions of linux too.

>In fairness to the low latency application people, I think that the
>RT Linux folks need to provide skeleton "apps" that show how to solve
>problems in the RT Linux space.  

The apps are not the central problem. The problems with RTLinux are:

    1) drivers: we'd need to port the whole of ALSA to RTLinux. Its
                not clear to me how much work this is, but I know its
		not trivial. Video people would also need FB drivers, etc.

    2) desktop-invisibility: until RTLinux ships as part of a major
               distribution, it effectively does not exist for
	       our target user base

    3) portability: apps written for RTLinux are not portable to Linux
               without at the very least recompilation, and in other
	       cases, some redesign.

				  Whether that happens or not, the RT Linux
>approach is really brilliant and it is the right approach to the problem

>Get with the program, folks, use the best tool for the job.  No matter
>what Ingo does, it is a _fact_ that you can not get both good performance
>for a multi user time sharing operating system and real time applications.

well, if you word it exactly like that, sure. but lets change it very
subtly:

>No matter
>what Ingo does, it is a _fact_ that you can not get both good performance
>from a multi user time sharing operating system and real time applications.

 ^^^^
   instead of "for"

Benno's benchmarks show that you can, assuming you agree that
Linux+LL-patches is still a multi-user time sharing OS.

--p