Subject: Re: [linux-audio-dev] Re: Plug-in API progress?
From: Paul Barton-Davis (pbd_AT_Op.Net)
Date: pe syys 24 1999 - 18:54:45 EDT
>Here's a question... how does the latency compare amongst the core three
>streaming IPC mechanisms on the _same_ machine: sockets, pipes, and shared
>memory (with some sort of convention for using a ring buffer)?
>
>I know shared memory is supposed to be instantaneous (although there've
>been conflicting reports posted to the list recently), but it is not
>inherently a streaming interface, so you need to manage the ring buffer
>and locking yourself, which adds overhead.
>
>Are local sockets and pipes any different? What are the actual numbers?
i don't have actual numbers, but i do know the implementation model.
pipe latency is effectively the same as the time between the writer
calling write(2) and the reader being context-switched back in. this
is hard to predict, though if the reader is SCHED_FIFO, its
essentially on the order of <10usec. the actual data copying time is
almost completely ignorable.
a unix domain socket is effectively identical to a pipe, although
there is a small extra layer of fs code to go through; it doesn't add
more than 1usec to the usual pipe case.
shared memory should be instantaneous, but of course the context
switch time still plays a role, and in this case, the priority of the
reader makes no difference, since writing to shared memory doesn't
ever cause the kernel to believe that a reschedule is needed. so in
fact, shared memory could be slower than a pipe if used without an
accompanying system call that might cause a reschedule.
--p
This archive was generated by hypermail 2b28 : pe maalis 10 2000 - 07:27:12 EST