RE: a joint letter on low latency and Linux

[Benno Senoner]

You are completely right.

I was only pushing low latency so hard, because the
desktop user (smooth video/audio) expect it on today's machines.

Nobody dies if the audio drops out but it's disturbing too.
So for multimedia empirical benchmarking is quite adequate:
if you run complex stress tests and you do not get a dropout
within 24 hours, it's very probable that you are safe
99.9999% of time , which is completely ok when your job
is to record a CD without dropouts.

As for medical equipement: 
if you ask me I'd probably go for a memory protected microkernel
like QNX , since if some driver crashes you have a chance
that the OS survives, but on Linux , a buggy driver
could take the entire machine down and dragging the heart
of the patient with it.
:-)

for mission critical applications the most important is as much as
protection levels possible.
(perhaps using 3 different machines with the same processing
semantics which monitor each other and use the 2 out of 3 method
in case of processing inconsistencies (just like in spacecrafts). 

On Fri, 30 Jun 2000, Russell, Richard (DEH) wrote:
> > Well, I personally would rather see that nobody ever needed RTlinux at
> > all. I think hard realtime is a waste of time, myself, and 
> 
> The need for hard real-time comes when you have real-world requirements that
> require absolute timing garantees with 100% reliability. For eg, a
> heart-lung machine needs to send out signals at a perfectly regular time. If
> cron suddenly decides to run mkwhatis or something, and you get a minor
> unevenness in the signal generated, you have a problem. The other 99.9% of
> the time, the CPU will be fast enough to compensate, but you need a 100%
> garantee in some situations. (how would it be if once in every 1000 days,
> someone on a heart-lung machine dies  because the computer used couldn't
> give hard timing garantees?). Yes, most problems (say audio streaming) don't
> have this true _hard_ real-time requirement, but some do, and it's these
> that really matter. Another thing to consider is that some hard real-time
> requirements actually require significant processing, and as such, the
> margin for error is much lower, and present CPUs are not "overwhelmingly
> fast enough"... :)
> 
> <snip>
> 
> > I definitely agree with low-latency requirements even in a 
> > standard Linux.
> > I just disagree violently with doing them with horrible 
> > cludges instead of
> > working on doing it right.
> 
> Absolutely, but there is a need for an OS that can give hard real-time
> garantees. Maybe it is innapropriate to try to make Linux do this at once --
> if there is no way of doing it that is not a kludge, it probably should be
> done using a different kernel. There are some requirements (eg hard
> real-time vs efficiency in other situations) that may be fundamentally
> incompatible, and should probably be solved separately.
> 
> rr
-- 
Benno Senoner
E-Mail: [e-mail]
Linux low-latency audio / scheduling latency benchmarks
http://www.gardena.net/benno/linux/audio