[zeromq-dev] IPC latency

[Erik Rigtorp]

On Thursday, January 7, 2010, Martin Sustrik <sustrik at 250bpm.com> wrote:
> Erik Rigtorp wrote:
>
> Hi!
>
> Following the IPC discussion i just wanted to post some code for IPC
> latency measurement that I wrote. It is kind of crude.
>
> http://github.com/rigtorp/ipc-bench
>
>
> Wow. Useful!
>
>
> From what I've seen, on Solaris and my hardware all the ones involving
> file descriptors takes roughly 10µs. The busy waiting shared memory
> version takes ~0.5µs. On Linux I get similar values except for TCP
> sockets which has about 5 times the latency of the other benchmarks
> involving file descriptors. Please try on your systems and see what
> you get.
>
>
> Ok. Standard x86-64 desktop, 2.6.31 Linux:
>
> tcp: max:182.565us min:22.613us
> spair: max:41.658us min:6.718us
> shm: max:1968.037us min:0.090us
> queues: max:4039884.997us min:4.026us
> pshm: max:8472.107us min:6.221us
> pqueues: max:7969.572us min:3.709us
> pipes: max:38.004us min:4.432us
> pipes-busy: max:15.967us min:1.103us
>
> I am not reporting averages as there's obviously some problem with it. The figures are constantly dropping as the test runs rather than stabilising at some value.
>
> My guess is that you are never reseting min, max and avg values during the test. I would suggest to reset the values once in a while to get unbiased results.
>
> Aside of that, it seems that you are considering time to print the results to be part of latency.

Well I said it's crude. The interesting part is the relative
latencies. Obviously it's worth implementing a unix domain socket
transport.

Feel free to improve the code.

Also note the pipe busy reading lowers latency. It should be possible
to do the same with poll/select/epoll.