linuxaudio.org

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

Content-Type: text/plain; charset="iso-8859-1"

Content-Transfer-Encoding: quoted-printable
> From: clemens@ladisch.de

quoted text
> To: nickycopeland@hotmail.com

> CC: d@drobilla.net=3B linux-audio-dev@lists.linuxaudio.org

>

> Perhaps I should revisit another project I was working on which was syslo=

g event

quoted text
> correlation: it used multiple threads to be scalable to >1M syslog per se=

cond

quoted text
> (big installation). I was testing it with socketpair()s and other stuff. =

I would be

quoted text
> interested to know if scheduler changes affect it too.

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