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 Sun, 09 Jul 2000, yodaiken@fsmlabs.com wrote:
> On Sun, Jul 09, 2000 at 01:25:30AM +0400, Khimenko Victor wrote:
> > In <20000708203335Z4895-532+18680@nic.funet.fi> Juhana Sadeharju (kouhia@nic.funet.fi) wrote:
> > > It would be very silly to talk that Linux would have 1 ms latency
> > > if it reaches it only once a week.
> >
> > Hmm. Why not ?
>
> Please remember that "once a week" is pretty vague. "once a week"
> during what load, with what variance, ...
> Suppose Linux will, once every now and then have
> 5 millisecond latency 10 times over a 2 minute period, but then go
> "typically" three weeks before going over 4 milliseconds. Is that ok?

Well, basically, if you get one single peak that the I/O buffering
can't handle, you get a drop-out, and if you're doing something
critical, you have lost a few minutes of work. That's pretty serious
if it happens more frequently than the usual studio stuff, like tapes
getting eaten, unreliable cables and the like. Preferably it should
never happen at all, but even digital mixing desks with dedicated
DSPs crash occasionally...

The "10 times over a 2 minute period" part is interesting, though.
Provided we use enough buffering to deal with the 5 ms peak. In that
case, a single 5 ms latency would use up just about all the headroom
the CPU load and buffering allows; the CPU will catch up after a
while. However, if *another* 5 ms peak should occur before the
buffering is back to normal, there may well be a drop-out.

That is, peaks aren't a problem, provided

1) there is enough buffering to deal with one peak, and

2) that there will never be less than T ms between two peaks,
where T is the time it takes to catch up after one peak.

If latency peaks occur at rather even intervals, and very rarely, the
probability of two or more such peaks occuring too close together,
thus accumulating too fast for the CPU to stay ahead, is extremely
low. This is the preferable distribution.

If it's like your example above, it's the distribution over those 2
minutes that's interesting, provided the software is set up to deal
with 5 ms latency peaks. (If not, it's game over after the fist peak
anyway - the user will probably be articulating various words
unsuitable for writing during the remaining 2 minutes!)

> > casing big delays). Have you ever written ANY program for Windows 3.x ? It's
> > basically the same problem. May be non-preeemptive linux kernel is bad thing
> > for current world and may be it can be even fixed. Just not this close to
> > 2.4 release: it's HUGE change.
>
> There is a good reason why Linux and other kernels as designed to be
> non-preemptive. To allow preemption, you must introduce locks around
> all critical data structures and these locks both can cause bugs and
> certainly add overhead -- especially in today's highly cached processors.

So, is it at all possible to get 2.2.x-lowlatency class RT without
breaking the kernel, or are there too many operations that inherently
take too long, and cannot be fixed? It seems rather illogical to me
that huge atomic operations could safely be preempted one way or
another, but then again, perhaps it's not *that* bad...?


//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@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.145 / U:0.248 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site