Re: a joint letter on low latency and Linux

[David Lang]

Larry, I am not an expert either, but it looks as if you are missing part
of this.

On Thu, 29 Jun 2000 [e-mail] wrote:

> > 
> > Do you really think that the multimedia driver folks are willing to port
> > hundreds of thousand of lines to the RTLinux model and then mantain 2 sets of
> > APIs to satisfy the realtime multimedia folks ?
> 
> What "hundreds of thousand of lines"?  I think your problem is that
> you think that if you use RTLinux then you have to do everything inside
> RTLinux.  That's not the case at all.  You do the part that can't have
> jitter there but the data processing is all down under Linux as it
> is today.  
> 
> It's true that I'm not an expert in this area so my I'm completely wrong,
> educate me.  My understanding is pretty basic - there are input channels
> and output channels and these have to be sampled at a constant rate, with
> no delays, right?  And the basic issue is that if we are doing disk I/O
> (or whatever) then the deadline is not met, right?
>
> And since you are insisting that ypu do not want to run in kernel mode,
> then I can assume that most of the work happens in user space, but the 
> sampling happens in the drivers, right?
> 
> If that's not right then please tell me how it works.  If that is more or
> less right, then it seems to me to be trivial to open up a pipe to a real
> time process which does the sampling and away you go.  
> 

it's more then just sampling and storing the data. they are currently
using the approach that you describe (drivers do the IO, processing in
user space. the trouble is that the user space processing can be delayed
to the point that you get a buffer underrun so if you use RTLinux to fix
this then your userspace code needs to be converted to RTLinux code. Thus
the "thousands of lines of code" that need to be converted.

The multimedia stuff doesn't need an absolute guarentee (if it did it
could never run under windows) it needs a reasonable expectation. from
what has been posted if <100ms is needed the current linux code is
expected to fail approx once per min. this is not acceptable, but if the
failure rate was once per week it would be very acceptable (given the
alturnatives of windows that will crash the whole system in less time then
that :-) so while the statement is "max latency <5ms" it is probably a
better statement to say "max latency <5ms 99.9% of the time" 

David Lang

> On the other hand, if you are doing all the work in the kernel or in the
> drivers, then the portability argument goes away because you have to port
> all that glop to Windows/whatever.
> 
> My guess is that it is close to what I think it is and that you don't realize
> that the point of the RTLinux APIs is to give you a small amount of code that
> does exactly what you want when you want it and then passes the results out to
> exactly the same user level processing you would use today.  
> 
> So educate me, tell me what I don't understand.
> 
> > - target audience : how many of the of the millions of linux desktops have
> > RTLinux installed
> 
> This is the same crock of sh*t that MIS directors used against Linux
> itself: "How many machines from Compaq come with Linux installed?"
> 
> Of course the standard distributions don't have it, there aren't apps that
> need it yet.  But you get busy and make some whizzy apps that work flawlessly
> under RTLinux to give you great sound and video and watch how fast Red Hat
> ships with RTLinux.  Using the "it isn't shipping yet" argument is wacko -
> the same can be said for every new idea.  If we used your logic, nothing
> new could _ever_ happen.
> 
> > The frustrating thing is that Ingo's patch although ugly, can cover
> > ALL realtime multimedia needs NOW
> 
> Really?  So you've done the analysis and testing to show that this is true
> for "ALL realtime multimedia needs NOW"?  You know what, I don't believe that.
> Show me.
> 
> > - too restrictive : problems with large memory needs, 
> >  working in kernelspace (do we really want to run COMPLEX apps within the
> > kernel space (a physical modelling synth) ? , 
> 
> No, you don't, and nobody is telling you to do so.  Just gather the data
> you need in the RT part and send it out to Linux just as you do today.
> 
> [other complaints about young technology deleted]
> 
> > So why should I use RTLinux which can do 20-50usec when 99.99% of cases can be
> > covered using and userspace app running SCHED_FIFO / mlock()  because most
> > apps do not need <5msec latencies. 
> 
> Because RTLinux can give you what you need.
> 
> Because it doesn't require you to hack up the kernel.
> 
> Because it is far more scalable and reliable.
> 
> Because it is cool.
> 
> Because your approach is the same tired bag of mistakes that helped make
> other operating systems piles of sh*t.
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [e-mail]
> Please read the FAQ at http://www.tux.org/lkml/
>