Re: a joint letter on low latency and Linux

On Thu, Jun 29, 2000 at 11:25:27PM -0400, Paul Barton-Davis wrote:
> >> 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. 
> 
> Sure, I was just being pedantic about Larry's example.

Have some mercy.

> 
> >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.
> 
> No good. 
> 
> This assumes it takes zero time for the linux process to do its
> thing. If you were running a faster clock, and could tell "ahead of
> time" that the linux process hadn't run yet, you could recover. but
> otherwise, the RTLinux process is going to run because an audio
> interface interrupted, and by that time, it will be too late to try to
> generate the data that should have been computed already. Recall: the
> RTLinux consumer's job is to move data from shared mem down to the
> audio interface. If the data is not ready when it runs, its already
> too late.

I'm adding a feature to our RTLinux consumer. It collects a frame
and dumps it, then it looks at the queue -- if the queue is at a low
water mark, the RT consumer reaches down into Linux, sets need_resched and 
boosts the priority of the Linux process, if Linux is in user
mode it might even be worthwhile to generate a timer interrupt
for Linux. This "runs a faster clock" and can look ahead.

I want to try this trick on TCP/IP sometime. 

> 
> >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.
> 
> the requirement that we have is primarily that interrupts are not
> disabled for more than some fraction of the audio interface interrupt
> interval. if this is guaranteed, then we know that we'll service the
> audio interface interrupt within a suitable short time after it
> occured, at which time, we will discover a SCHED_FIFO task is ready to
> run again, and we'll run it.
> 
> to put this another way: we have our own clock source, and we use
> SCHED_FIFO to override the default scheduler. all that matters is that
> our clock source is not disabled. if its not, then we will regularly,
> and on-schedule, be awarded the processor. if the SCHED_FIFO thread is
> using mlocked memory and does not block on anything other than io
> to/from the audio interface, then it will always run on time, and in
> time (assuming its not trying to do too much work).
> 
> i hope i got this right, because this is an important re-casting of
> what is important for these kinds of apps. its not about latency
> per-se, although that certainly matters. its about making sure that
> the audio interface interrupts result in our task getting back onto
> the processor promptly.

I don't get the distinction. Worst case latency between the audio
interface and the running of the app seems to be your concern.

> 
> --p
> 

-- 
---------------------------------------------------------
Victor Yodaiken 
FSMLabs:  www.fsmlabs.com  www.rtlinux.com
FSMLabs is a servicemark and a service of 
VJY Associates L.L.C, New Mexico.