Re: [LAD] Pipes vs. Message Queues

Previous message: [thread] [date] [author]
Next message: [thread] [date] [author]
To: <clemens@...>
Cc: <linux-audio-dev@...>
Date: Friday, November 25, 2011 - 2:21 pm

--_1b9fcbd8-7534-46c1-9ddf-e17cc830b019_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

> From: clemens@ladisch.de

g event
cond
I would be

So if the pipe() is replaced with=20

socketpair(PF_UNIX=2C SOCK_STREAM=2C PF_UNSPEC=2C pipe_fd)=3B

Then the issue I was seeing goes away. Perhaps the pipe() code has not been=
=20
optimised since sockets were developed to replace them when IPC suddenly=20
needed to be between hosts rather than processes? Pure conjecture.

[nicky@fidelispc] /tmp [148] cc ipc.c -lrt -DSET_RT_SCHED=3D1
[nicky@fidelispc] /tmp [149] ./a.out 4096 10000000
Sending a 4096 byte message 10000000 times.
Pipe send time: 26.131743
Pipe recv time: 26.132117
Queue send time: 18.576559
Queue recv time: 18.576592

The results were repeatable=2C CPU load was evenly distributed and the ludi=
crous
context switching figures were gone. Perhaps I should have replaced 'Pipe s=
end time'=20
with 'Socket send time'? The message queues seem to maintain the best resul=
ts.
Somebody should compare that to a shared memory lockless ringbuffer althoug=
h
I have a feeling they will not exceed the messages queues used here.

Regards=2C nick.
=

--_1b9fcbd8-7534-46c1-9ddf-e17cc830b019_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

&gt=3B From: clemens@ladisch.de&gt=3B To: ni=
ckycopeland@hotmail.com&gt=3B CC: d@drobilla.net=3B linux-audio-dev@lis=
ts.linuxaudio.org&gt=3B&gt=3B Perhaps I should revisit another proj=
ect I was working on which was syslog event&gt=3B correlation: it used =
multiple threads to be scalable to &gt=3B1M syslog per second&gt=3B (bi=
g installation). I was testing it with socketpair()s and other stuff. I wou=
ld be&gt=3B interested to know if scheduler changes affect it too.<=
br>So if the pipe() is replaced with &nbsp=3B&nbsp=3B&nbsp=3B socke=
tpair(PF_UNIX=2C SOCK_STREAM=2C PF_UNSPEC=2C pipe_fd)=3BThen the is=
sue I was seeing goes away. Perhaps the pipe() code has not been optimi=
sed since sockets were developed to replace them when IPC suddenly need=
ed to be between hosts rather than processes? Pure conjecture.[nick=
y@fidelispc] /tmp [148] cc ipc.c -lrt -DSET_RT_SCHED=3D1[nicky@fidelisp=
c] /tmp [149] ./a.out 4096 10000000Sending a 4096 byte message 10000000=
times.Pipe send time:&nbsp=3B 26.131743Pipe recv time:&nbsp=3B 26.=
132117Queue send time: 18.576559Queue recv time: 18.576592T=
he results were repeatable=2C CPU load was evenly distributed and the ludic=
rouscontext switching figures were gone. Perhaps I should have replaced=
'Pipe send time' with 'Socket send time'? The message queues seem to m=
aintain the best results.Somebody should compare that to a shared memor=
y lockless ringbuffer althoughI have a feeling they will not exceed the=
messages queues used here.Regards=2C nick. =

=

--_1b9fcbd8-7534-46c1-9ddf-e17cc830b019_--

Previous message: [thread] [date] [author]
Next message: [thread] [date] [author]

Messages in current thread:
[LAD] Pipes vs. Message Queues, David Robillard, (Fri Nov 25, 12:10 am)
Re: [LAD] Pipes vs. Message Queues, Nick Copeland, (Fri Nov 25, 11:07 am)
Re: [LAD] Pipes vs. Message Queues, Clemens Ladisch, (Fri Nov 25, 12:33 pm)
Re: [LAD] Pipes vs. Message Queues, David Robillard, (Fri Nov 25, 8:51 pm)
Re: [LAD] Pipes vs. Message Queues, Nick Copeland, (Fri Nov 25, 2:00 pm)
Re: [LAD] Pipes vs. Message Queues, Nick Copeland, (Fri Nov 25, 2:21 pm)
Re: [LAD] Pipes vs. Message Queues, David Robillard, (Sat Nov 26, 12:00 am)