Subject: Re: [linux-audio-dev] MuCoS, Glame, API Issues
From: Benno Senoner (sbenno_AT_gardena.net)
Date: pe maalis 10 2000 - 09:49:21 EST
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.
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
:-)
Anyway Ingo and friends modified the scheduler in order to reschedule
SCHED_FIFO task more often when needed,
that means critical routines such as disk I/O etc, now regularly
if a process is ready to run.
Ingo patched most critical sections, like disk, console, keyboard,
buffer cache, inode allocation, process forking etc.
"latencytest" was used to monitor the progress.
(For example I discovered that booting the kernel with
various mem= options ( 64M , 128M, 256M )
the latencies increased , this turned out to be due to
the fact that when writing to disk, the inode management routines
were O(n), n = RAM size.
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.
> >
> > 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.
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.
Under linux we have now 3ms latency + FULL multitasking , and that is what
we want.
Linux is now one of the OSes of choice for doing realtime stuff,
(from a technical point of view), if you like it or not.
When doing my first lowlatency tests (before INgo developed the patch) I hoped
that one day linux could achieve <10ms.
After I measured 3ms on my P133, I was amazed, and
even David Olofson, a big freak of RTLinux said that RTLinux wouldn't be needed
anymore for doing reliable audio processing under Linux.
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.
I spent very much time in this area during the last 8 months doing hours and
hours of testings, instead of doing "useful stuff" (making money :-)) )
therefore I can say that I have SOME experience in this area.
I think that I furnished enough proofs, and tools , so that everyone which is
interested can reproduce my results.
there is zero FUD out here.
Benno.
This archive was generated by hypermail 2b28 : su maalis 12 2000 - 09:14:06 EST