Messages in this thread | | | From | David Olofson <> | Subject | Re: [linux-audio-dev] lowish-latency patch and toolchain | Date | Sun, 9 Jul 2000 05:57:38 +0200 |
| |
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/
| |