On Sun, Jul 02, 2000 at 11:22:43PM +0200, Mike Galbraith wrote:
> On Sun, 2 Jul 2000, Paul Barton-Davis wrote:
> >
> > Except that we've had, in your words "excellent explanations that this
> > is by definition asking for hard RT". So if the problem really has
> > been ACKed, which I think I accept it has, and if there is really some
> > sense that it should be solved, which there might be, doesn't this
> > imply, in your own words, that Linux has to incorporate hard real-time ?
>
> ?? everything _I_ read said that is stupidity for a GP OS (Linux). 'if
> there is really some sense that it should be solved' you say?? Well,
> come on.. the volume of traffic in this thread combined with some of the
> persons (who didn't mumble) when they responded make that quite clear.
>
Arguably, decent support for multimedia processing
may be entering the province of a "general purpose" OS.
It's certainly not the specialty application it once was,
given that you can head down to Frey's and walk out with
an iMac DV.
Paul &co. are not talking about anything like interrupt
latency approaching the HW limits; they're talking about
latency over two orders of magnitude higher, in the common
case, and on the order of the worst case scenario with
decent hardware (assuming people doing realtime DSP won't
try to do it on PIO-only IDE drives).
Benno's tests showed spikes of 300ms. 300ms interrupt
latency _sucks_! That's easily a human-perceptible amount.
And these folks aren't (any more) trying to force a change
into the kernel, they're just trying to figure out what
types of changes would be acceptable.
In the short term, is there currently support for pinning
processes and interrupts to a processor in an SMP system?
Anyone buying a machine for pro audio can easily afford
SMP, and being able to attach an interrupt and a process
to a CPU (and allow no others on that CPU) is very
close to something Linux could do now (possibly it _is_
something that can be done now, I haven't looked at the
2.4 interrupt handling code). It's a lot like using a
CPU as an easier-to-program DSP.
miket
-
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/
This archive was generated by hypermail 2b29 : Fri Jul 07 2000 - 21:00:14 EST