[zeromq-dev] UDP performance

Bennie Kloosteman bklooste at gmail.com
Wed Nov 28 00:41:33 CET 2012


Depends, in a very low  loss environments and with nagle turned off
probably less than 2% difference in latency.  I find in 90% of cases people
who use UDP end up writing 70 or 80 % of the TCP stack eg piggy backing
packets , windowing and acks and end up with similar performance. In a low
to medium loss environment  you can get some benefits by removing the worst
case and loss  by spamming multiple udp packets ( you can get a order of
magnitude improvement in worst case performance)  but  then again firewalls
are an issue.. Also note most routers will drop UDP packets before TCP when
they are under stress.

>The overall end-to-end latency between a zmq_msg_send() in one application
on one host and zmq_msg_recv() in another application on the same host over
the loopback interface is just too high for what we need

UDP on the wire will not be better than  any system using a tcp loop-back.
I suggest your requirement may  not  be feasible. A congested environment
is far more of a latency issue then TCP/UDP and you would almost certainly
be better of  adding a few NICs  just for the high performance channel (
cheaper too) .

Note never measure the latency of the first packet on tcp a lot of setting
up is done.

Ben

On Wed, Nov 28, 2012 at 6:25 AM, Dan Goes <DGoes at blueorigin.com> wrote:

> _send() in one application on one host and zmq_msg_recv() in another
> application on the same host over the loopback interface is just too high
> for what we need. Initial profiling suggests that a non-negligible amount
> of that latency is bound up in zeromq and networking land. Is it possible
> to take a swing at how significant a decrease we would see in this latency
> by using UDP instead? I.e., are we talking an order of magnitude, or more
> like 5-10%? Ultimately, we'll have messages sent inter-host instead of
> intra-host, and our environment is not inherently lossy, but possibly
> congested. That is, a lot of small messages are going out frequently, but
> the total throughput experienced by the network is unlikely to be high. The
> drawbacks of U
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20121128/d1253662/attachment.htm>


More information about the zeromq-dev mailing list