Re: a joint letter on low latency and Linux

On Fri, Jun 30, 2000 at 09:59:05PM -0400, Paul Barton-Davis wrote:
> >This all came up before in a previous flamewar.  Reducing Linux's
> >scheduling latency and overhead is good.  Trying to make Linux serve the
> >contradictory goals of being both a good timesharing OS and a good
> >realtime OS is not.  Thinking that you are making Linux into a realtime
> >OS by reducing scheduling latency and overhead is a fallacy.
> 
> Sorry, but this is nonsense. Not because you're wrong about the
> distinction between a TS and an RT OS. You're wrong because we don't
> need the full set of features that an RT OS comes with.

The distinction that makes something hard RT is 
purely and simply the ability to promise worst case timing. There
is no "full set of features" that makes any sense outside of that.
If your application dies because a timing deadline is missed, then the
application has a hard realtime constraint. If the application can 
survive a couple of missed deadlines over some defined time period,
then the application is soft realtime. 

> Imagine that Linux was a preemptable kernel (I'm *not* advocating it,
> just using it as an example), and we ensure that our audio thread has
> the highest SCHED_FIFO priority, and we ensure that interrupts are
> never disabled for more than a few usecs. 

That is, imagine that Linux guarantees that the highest priority
thread runs within some T usecs.  Then Linux would be a RTOS.

> A true RT OS can make much broader guarantees about resource
> availability and so forth. we (the audio+MIDI linux community) are
> *NOT* asking for that. 

You cannot ask for a timing guarantee and not ask for a RTOS -- and
even most, so-called RTOS's don't  provide this. 

> We know that if our thread does disk i/o or ends up paging, it could
> block for an indeterminate amount of time. we know that if its uses
> other system resources, it could fail to meet deadlines. thats
> *OK*. we can design audio threads to do the right thing (and in fact,
> we already do).

What you want is a subset of services that are RT safe.  That's 
very hard to do although it is not so hard to approximate.

> But as long as there is a the chance of a significant delay between
> the interrupt that makes our SCHED_FIFO audio thread runnable again,
> and it actually getting back on the processor, we can't make a number
> of very useful (and very fun) things work correctly.

I'm not advocating any particular approach to writing audio, but 
I am advocating some clarity about what you are asking for.
I think that Linux that 99% of the time has no delays of more than
10ms between set need_resched and process activation  is an achievable
and positive goal if done correctly. But if any 20ms delay over a, say
4 hour period, might turn your CD master into junk, you have a hard
realtime requirement and there is no way out of that. 

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