[zeromq-dev] Timing issues

Lindley French lindleyf at gmail.com
Thu Jan 16 14:04:13 CET 2014

Ah, that would explain it, yes. It would be great to have a way of
disabling Nagle's algorithm (TCP_NODELAY sockopt).

On Thu, Jan 16, 2014 at 4:24 AM, Bruno D. Rodrigues <
bruno.rodrigues at litux.org> wrote:

> Without looking at the code I assume ØMQ is not trying to send each
> individual message as a TCP PDU but instead, as the name implies, queues
> messages so it can batch them together and get the performance.
> This then means the wire will be filled up when some internal buffer
> fills, or after a timeout, which looks like 100ms.
> On the other hand I can’t see any setsockopt to configure this possible
> timeout value.
> Any feedback from someone else before I have time to  look at the code?
> On Jan 15, 2014, at 16:20, Lindley French <lindleyf at gmail.com> wrote:
> > I have a test case in which I'm communicating between two threads using
> zmq sockets. The fact that the sockets are in the same process is an
> artifact of the test, not the real use-case, so I have a TCP connection
> between them.
> >
> > What I'm observing is that a lot of the time, it takes ~100 milliseconds
> between delivery of a message to the sending socket and arrival of that
> message on the receiving socket. Other times (less frequently) it is a
> matter of microseconds. I imagine this must be due to some kernel or thread
> scheduling weirdness, but I can't rule out that it might be due to
> something in 0MQ.
> >
> > If I follow the TCP socket write with one or more UDP writes using
> Boost.Asio, the 100 millisecond delay invariably occurs for the ZMQ TCP
> message but the UDP messages arrive almost instantly (before the TCP
> message).
> >
> > My design requires that the TCP message arrive before *most* of the UDP
> messages. It's fine if some come through first----UDP is faster after all,
> that's why I'm using it----but this big of a delay is more than I counted
> on, and it's concerning. I don't know if it would apply across a real
> network or if it's an artifact of testing in a single process.
> >
> > Any insights?
> > _______________________________________________
> > zeromq-dev mailing list
> > zeromq-dev at lists.zeromq.org
> > http://lists.zeromq.org/mailman/listinfo/zeromq-dev
> _______________________________________________
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20140116/ae0ad191/attachment.htm>

More information about the zeromq-dev mailing list