Linux-kernel mailing list archive 2000-26,: Re: a joint letter on low latency and Linux

# Re: a joint letter on low latency and Linux

Jussi Laako (jussi@jlaako.pp.fi)
Sat, 01 Jul 2000 18:11:43 +0300

- Messages sorted by: [ date ][ thread ][ subject ][ author ]
- Next message: Paul Barton-Davis: "Re: Low Latency Patch"
- Previous message: Chris Wedgwood: "fork then wait4 bug when being traced?"
- Maybe in reply to: Paul Barton-Davis: "a joint letter on low latency and Linux"
- Next in thread: Paul Barton-Davis: "Re: a joint letter on low latency and Linux"

> > The frustrating thing is that Ingo's patch although ugly, can cover
> > ALL realtime multimedia needs NOW
>
> Really? So you've done the analysis and testing to show that this is
> true for "ALL realtime multimedia needs NOW"? You know what, I don't
> believe that.
> Show me.

No it doesn't, but brings it closer. I think the truth is somewhere between
your opinions.

What I need is:

- Streaming audio over network from multiple servers with
latencies < 5 ms (TCP connection)
- Server must be able to run on PC/104 machine

I can also accept longer latency, but "phase shift" between streams from two
servers must be < 5 ms. Connections could be made at different times. It's
much harder to synchronize multiple streams when there is a lot of
buffering.

We should also be able to assign I/O priorities. Now disk I/O can stall
network I/O. (Bus bandwith limits / device and bandwidth limits / process
would be nice too... ;-) ) This is application specific, in some
applications disk I/O can wait almost forever!

To do this under RT-Linux requires writing sound/DAQ-card drivers, NIC
drivers, TCP/IP stack... Lot of work! All this is already in standard Linux
kernel.

I know this is problematic to implement, but we could have some config
option "Optimize for speed or latency".

This can be implemented in RTOSes, but those are too expensive for me. I
have BeOS, but haven't implemented software yet. Just been waiting for free
QNX and inclusion of RTMX (or-whatever-it-was) to OpenBSD.

Complete path is: sound card -> server process -> TCP stream -> player
process -> soundcard
...all this should happen < 5ms from input to output. And there can be many
of these and quite a lot of different paths.

- Jussi Laako

    --
    PGP key fingerprint: 161D 6FED 6A92 39E2 EB5B  39DD A4DE 63EB C216 1E4B
    Available at: ldap://certserver.pgp.com, http://keys.pgp.com:11371

    -
    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/

- Next message: Paul Barton-Davis: "Re: Low Latency Patch"
- Previous message: Chris Wedgwood: "fork then wait4 bug when being traced?"
- Maybe in reply to: Paul Barton-Davis: "a joint letter on low latency and Linux"
- Next in thread: Paul Barton-Davis: "Re: a joint letter on low latency and Linux"