linuxaudio.org

On Fri, 2011-11-25 at 15:21 +0100, Nick Copeland wrote:

[...]

quoted text
>

> So if the pipe() is replaced with

>

>     socketpair(PF_UNIX, SOCK_STREAM, PF_UNSPEC, pipe_fd);

>

> Then the issue I was seeing goes away. Perhaps the pipe() code has not been

> optimised since sockets were developed to replace them when IPC suddenly

> needed to be between hosts rather than processes? Pure conjecture.

Added sockets:
Normal scheduling:
$ ./ipc 4096 1000000

Sending a 4096 byte message 1000000 times.

Pipe recv time:  7.048740

Pipe send time:  7.048648

Socket send time:  2.365210

Socket recv time:  2.365292

Queue recv time: 2.072530

Queue send time: 2.072494
SCHED_FIFO:
$ ./ipc 4096 1000000

Sending a 4096 byte message 1000000 times.

Pipe send time:  5.279210

Pipe recv time:  5.279508

Socket send time:  2.709628

Socket recv time:  2.709645

Queue send time: 5.228892

Queue recv time: 5.228980
Interesting.  I find sockets being significantly faster than the much

simpler pipes quite counter-intuitive.
Code at the same location:
http://drobilla.net/files/ipc.c
What would be a more interesting/relevant benchmark is to spawn p

processes, and have each send a message to the next in a chain.  Measure

the time from the start until the very last process has received the

message.  That should give us a pretty good idea about the sort of

scheduling behaviour we actually care about, and you can crank up p to

make the difference very apparent.
Science is fun.
-dr
_______________________________________________

Linux-audio-dev mailing list

Linux-audio-dev@lists.linuxaudio.org

http://lists.linuxaudio.org/listinfo/linux-audio-dev