Messages in this thread | | | From | David Olofson <> | Subject | Re: [linux-audio-dev] lowish-latency patch and toolchain | Date | Sat, 8 Jul 2000 21:02:23 +0200 |
| |
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/
| |