Re: a joint letter on low latency and Linux

[Magnus Danielson]

From: [e-mail]
Subject: Re: a joint letter on low latency and Linux
Date: Thu, 29 Jun 2000 21:08:42 -0600

> On Thu, Jun 29, 2000 at 09:19:56PM -0400, Paul Barton-Davis wrote:
> > >OK, now we are getting somewhere.  So I have a kernel level source, user
> > >level processing, and a kernel level sink, right?  And the problem is that
> > >we can have long delays which mess that up.  Here is how you handle that
> > >with RTLinux:
> > >
> > >There are three processes:
> > >
> > >    RTLinux producer
> > >	for (;;) {
> > >		sample();
> > >		put_data_in_shared_mem();
> > >		up(producer_sema);
> > >	}
> > >
> > >
> > >    Linux processor
> > >
> > >	for ( ;; ) {
> > >	    down(producer_sema);
> > >	    get_data_from_shared_mem();
> > >	    process();
> > >	    put_processed_data_in_shared_mem();
> > >	    up(consumer_sema);
> > >	}
> > >
> > >    RTLinux consumer
> > >	for ( ;; ) {
> > >	    down(consumer_sema);
> > >	    move_shared_mem_to_device();
> > >    	}
> > >
> > >I think that 99,000 out of the 100,000 lines of code still lives in the
> > >Linux process just like it always did.  The only difference is that the
> > >RT processes get scheduled when they need to get scheduled - the Linux
> > >kernel and all of it's processes get preempted any time a RT process
> > >wants to run.
> > 
> > OK. And what happens when "linux processor" stalls for 65ms because of
> > linux ? The RTLinux consumer doesn't have the data it needs (actually,
> > it doesn't run, if the semaphores work as expected), and we get an
> > audio dropout.
> 
> A) You don't use semaphores, you use well known methods that are lock
>    free. 
> 
> B) If the RT consumer finds low data, it can take an emergency action to
>    force Linux to run the "linux processor" next. If the clock is
>    ticking at 10 milliseconds, we will be fine -- assuming the app 
>    works on a stream.
> 
> 
> BTW: I'm agnostic about how audio applications, in general, should
>     be written but I do have two observations:
>      1. Hard realtime deadlines are hard realtime deadlines. To say that
>         you "only" need to run ever 5miliseconds is to say you need 
>         a hard realtime system.  You don't need realtime only when 
>         "average" case or some other statistical measures is good enough.
> 
>      2. Even when you just need QOS (quality of service) statistical
>         timing, you need some underlying hard RT to enforce QOS when
>         times get out of line: if missing 5 frames a minute is ok, but 6
>         is not, you need to enforce timing when 4 or 5 frames have dropped
>         in the last 50 seconds.

This could be said like this:

You can make efficient lower degree service out of a higher degree
service but you can not make an efficient higher degree service out of
a lower degree service.

High degree service: deliverance (by transport or processing) of
information (data transported or content in memory/registers) at
equallydistant events in time or with a constant delay from initiation
to completion of operation.

Low degree service: deliverance of information with no guarantee of
deliverance at equally distance or after (the intended) initiation of
the operation.

Then there are many degrees inbetween where most of the stuff really
operates.

An CPU in its most fundamental form provides what could be viewed as
the highest degree service. Caches are examples of stuff which breaks
the picture up.

Cheers,
Magnus