Subject: Re: [linux-audio-dev] MuCoS, Glame, API Issues
From: David Olofson (david_AT_gardena.net)
Date: la maalis 11 2000 - 21:49:02 EST
On Fri, 10 Mar 2000, Benno Senoner wrote:
> On Fri, 10 Mar 2000, Richard Guenther wrote:
>
> > > Standard Linux, yes. With the lowlatency patch (and hopefully 2.4),
> > > this is no longer the case.
>
> a low-latency kernel isn't hard-realtime, but it is to certain extent
> when the SCHED_FIFO thread avoids nondeterministic
> syscalls withing the DSP loop.
> That means no disk access allowed, no syscall which could block
> for too long time.
This isn't much worse than coding for a "true" RTOS. There are always
conflicts between non RT subsystems, and between RT subsystems with
longer worst case latencies, so you can *never* assume that all calls
are RT safe in *any* RTOS that even remotely resembles a real OS.
> For example write() to the audio device works fine since this call
> doesn't do nondeterministic stuff. (the audio card accepts data at a constant
> rate)
>
> >
> > Err? Linux is not hard realtime - even with the lowlatency patch. Hard
> > realtime is about ensuring a maximum latency for everything. (Of course if
> > you set this latency to 1 hour, linux is hard realtime ;)) Linux with the
> > lowlatency patch can only guarantee that f.i. you get <10us latency with
> > a high probability - this is not hard realtime.
>
> even windows is hard-realtime when you set 1hour as peak-latency
> :-)
Hmm... Honestly, I'm not sure. The "spontaneous crash rate" is so
high that it has to be taken in account when dealing with that kind
of figures. (Just as the reliability of the hardware has to be taken
in account when running RT communication, or when running MCUs in
environments that have so much noise that the MCU *will* crash and
reboot occasionally.)
The main reason why WinNT would never be considered for a life
supporting medical system is not that it can't do better than some ms
worst case latency (it can with *lots* of work - forget about user
space) - is is because it will most probably crash before it misses
an RT deadline...
> I can only say if you get for 18 consecutive hours NO DROPOUTS
> with a 3ms buffer, under EXTREME , (and with extreme I mean extreme)
> conditions then I call this kernel SUITABLE for high-end
> audio, no matter if you call it hard-real time or not.
There is *no such thing* as a system that can be considered true
hard real time. (Eventually, you will miss a deadline because your CPU
dies, or one of your DIMMs gives in.) So, seen from that perspective,
there are NO hard real time systems whatsoever in the real world! :-)
However, the test data suggests that lowlatency Linux kernels provide
pretty high quality hard RT for real use.
> > > Buffering has nothing to do with it! The definition of a hard real
> > > time system is that it can quarantee a correct response within a
> > > certain maximum time frame. That time frame might well be 2 hours,
> > > but it's still a hard real time system.
> >
> > Hehe :) There's the 2 hours... - make it say 1ms and linux will not meet
> > the criteria for hard realtime.
>
> this is absolute non-sense here.
>
> Make the deadline 1usec , and RTLinux , QNX and other RTOSes will
> not meet the deadlines.
RTLinux is close with the fastest Celerons, but yes, it will fail
every now and then...
> Plus consider the fact that using latencies <1ms and running large
> plugin-chains you end up in spend more time in callback and subroutine calls
> (stack etc), than in doing actual useful work.
Yes, and this is why a plugin API should allow efficient code. There
isn't room for lots of checks of this and that for every plugin call,
and no task switches. BTW, this effect also comes to life in feedback
loops regardless of the system being real time or not.
> Therefore the sceptics should please come up with facts, and bring me a
> testprogram (using my liblatency to record the graphs) which shows me
> that linux can't meet the 3-5ms deadlines under high load.
> then I will believe your claims.
...and if someone finds a way to get Linux to fail here, it will be
tracked down and fixed, as it's a bug. A kernel that's supposed to be
capable of SMP shouldn't fall asleep for a ms or two every now and
then. The RT latency and SMP (and some other) performance issues are
related, so this is not about a dirty performance hack for RT only.
//David
.- 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_AT_linuxdj.com -'
This archive was generated by hypermail 2b28 : su maalis 12 2000 - 09:14:06 EST