Re: a joint letter on low latency and Linux

[Paul Barton-Davis]

In message <[e-mail]>you write:
>> 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,
>
>Sure.  Go measure the code paths inside those operating systems and
>ask yourself why is it that the same system call on IRIX can take 10-15
>times as long as the same system call on Linux.  

Would it be possible for you to admit that you don't know anything
about how BeOS does this ? I've listened calmly and respectfully to
you for several years tell us many times just how f*cked and sh*tty
IRIX is, and I sincerely hope that everyone working on Linux has
learnt something from your accounts. But BeOs isn't IRIX, and it
doesn't have 15x overhead for *anything* compared to Linux. In fact,
for just about everything, its either as fast or faster than
Linux. Major exceptions have to do with its network stack and in some
cases, non-streaming-disk-I/O. 

>> 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. 
>
>Really?  Sure sounds like hard real time to me.  It doesn't matter if
>the number is 1ns, 1us, or 1ms, a limit is a limit.

If I told you that the limit was 10 seconds, would you tell me to use
RTLinux ? 

Do you know that old (supposedly Russian) joke ? An old man says to a
beautiful young woman "Would you sleep with me for a million rubles ?"
She pauses, and says "I'd consider it". Then he asks her "Would you
sleep with me for a ruble?" Indignant, she exclaims "What do you think
I am, a whore ?" The old man says "We have already established what
you are. We are merely trying to determine your price."

>>From what I can tell, your whole approach is flawed.  You are just
>trying to solve your one problem.  If you were really serious, you'd be
>looking at doing 32 channels of audio and a couple of channels of video.
>All of a sudden, all of your numbers don't work anymore and you need
>more hackery in the kernel.

Sorry Larry, but you clearly don't get the picture here. Your
description of a supposed "problem" is wrong.

>This is really the crucial point.  Suppose Linus lets in some of

I'm glad you think its critical, because in fact, its almost irrelevant.

The latency characteristics of the kernel have *nothing* to do with
capacity handling for audio+MIDI (I know nothing about video). The
kernel right now can handle playback of several hundred channels of
audio without any problems. 

The proviso is: you can't do this without enormous amounts of
buffering to smooth out kernel scheduling jitter. So, as long as you
are playing back a pre-determined audio stream, just allocate as much
buffering as possible in the audio interface, plus plenty of memory
buffers for the data from/to disk, and it will work without any
problems on the current kernel.

What you cannot do right now with any reliability is to change the
output audio stream in real-time in response to external events (say,
different incoming audio or MIDI). It doesn't matter whether you're
dealing with one channel of audio or 200.

The only sense in which the number of channels matters is that
obviously, if the processing done per channel takes Nmsec, and
N*numchan exceeds the inter-sampling interval, you're screwed. Buts
that about raw processing power and scheduling priorities, not kernel
scheduling jitter.

--p