lkml.org 
[lkml]   [2000]   [Jul]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: [linux-audio-dev] lowish-latency patch and toolchain
Date
On Sat, 08 Jul 2000, Khimenko Victor wrote:
> In <20000708150210Z31499-532+18397@nic.funet.fi> Juhana Sadeharju (kouhia@nic.funet.fi) wrote:
> >>From: Andrew Morton <andrewm@uow.edu.au>
> >>
> >>doing silly things, the scheduling latency is reliably 4 milliseconds on
> >>a 500MHz machine. Very occasionally reaches 7 millisecs. It has been
>
> > Lets talk about 7 ms latency only -- 4 ms is useless information in audio
> > software which has to be 101% reliable.
>
> Sorry. It was said 1000 times already but I can repeat once more just for you:
> 101% reliability => HARD real time => RTLinux. Period. If you NEED 101%
> reliability then stop even THINKING about normal Linux already. It's NOT
> for you.

If Ingo's patch didn't provide hard real time, neither does RTL.
It's just a matter of what kind of peak latency the application
requires.

********************************************************************
The reliability is a function of the peak scheduling latency vs. the
maximum latency that the application can deal with.
********************************************************************

At some point, the biggest problem will be hardware failures rather
than missed deadlines, so there can never be exactly 100%
reliability. That's not really interesting to this discussion
though, so lets return to real life: Thorough testing of Ingo's
patch has been done, and the results indicate that the timing is
deterministic enough to be considered hard real time, for all
practical matters.

The Linux/lowlatency peak latency is a lot higher than that of RTL,
BUT the relation between multimedia and robotics timing requirements
is in the same order of magnitude! If you need RTL for "100%"
reliable RT audio a about 1000 schedules/s, what do you use to
control an industrial robot at 10000 schedules/s...?

> Of course. It's easy. Use RTLinux. You need it anyway (as you said you need
> 101% reliability) so what's the point of discussion at all ?

Speaking for myself, the point is that

* Ingo's lowlatency patch *does* provide adequate quality real time,

* it doesn't require porting code to a different environment,

* it doesn't break system security and stability entirely, as is
the case when the code has to run in unprotected kernel space.


Ingo's lowlatency patch *did* achieve the goal of taking the latency
to professionally usable levels, and even below the previously
"multimedia OS record" of 3 ms, held by BeOS. It even did so without
any messy "direct access" API, or working around the normal driver
API.

I'm not saying that this justifies messing up the mainstream kernel
- I fully agree that lowlatency should be implemented in an
acceptable way. But to dismiss "multimedia class" hard RT SCHED_FIFO
as impossible to do is to ignore facts. Maybe it IS impossible to do
in a nice way, and maybe it'll never go mainstream because of that,
but the figures we've seen, and the fact that Ingo's patch got us all
the way performance wise, indicates that it's not totally hopeless.


Either way, the only way to get *anywhere* is to dig in and hack some
code! I'm drowning in work and projects, and trying to understand the
code and do some real work seems to require optimizing my sleep away.
*hrmpf* OTOH, I might be able to take some vacation soon... :-)

Any guesses as to when it'll be definitely too late for this kind of
patches for 2.4?


//David


PS. I'm not on l-k these days - please CC to david@gardena.net.


.- M u C o S --------------------------------. .- David Olofson ------.
| A Free/Open Multimedia | | Audio Hacker |
| Plugin and Integration Standard | | Linux Advocate |
`------------> http://www.linuxdj.com/mucos -' | Open Source Advocate |
.- A u d i a l i t y ------------------------. | Singer |
| Rock Solid Low Latency Signal Processing | | Songwriter |
`---> http://www.angelfire.com/or/audiality -' `-> david@linuxdj.com -'

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:57    [W:0.091 / U:0.036 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site