http://www.aosabook.org/en/zeromq.html On Jan 16, 2014 4:55 PM, "Apostolis Xekoukoulotakis" <[email protected]> wrote:
> To reduce calls to the other layers and improve performance. > On Jan 16, 2014 4:53 PM, "Lindley French" <[email protected]> wrote: > >> Maybe I'm missing something, but what purpose is there in disabling >> Nagle's algorithm, only to then re-implement the same concept one layer >> higher? >> >> >> On Thu, Jan 16, 2014 at 9:15 AM, Charles Remes <[email protected]>wrote: >> >>> Nagle’s algo is already disabled in the codebase (you can confirm that >>> with a quick grep). I think what Bruno is referring to is that zeromq >>> batches small messages into larger ones before sending. This improves >>> throughput at the cost of latency as expected. >>> >>> Check out the “performance” section of the FAQ for an explanation: >>> http://zeromq.org/area:faq >>> >>> >>> On Jan 16, 2014, at 7:04 AM, Lindley French <[email protected]> wrote: >>> >>> 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 < >>> [email protected]> 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 <[email protected]> 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 >>>> > [email protected] >>>> > http://lists.zeromq.org/mailman/listinfo/zeromq-dev >>>> >>>> >>>> _______________________________________________ >>>> zeromq-dev mailing list >>>> [email protected] >>>> http://lists.zeromq.org/mailman/listinfo/zeromq-dev >>>> >>>> >>> _______________________________________________ >>> zeromq-dev mailing list >>> [email protected] >>> http://lists.zeromq.org/mailman/listinfo/zeromq-dev >>> >>> >>> >>> _______________________________________________ >>> zeromq-dev mailing list >>> [email protected] >>> http://lists.zeromq.org/mailman/listinfo/zeromq-dev >>> >>> >> >> _______________________________________________ >> zeromq-dev mailing list >> [email protected] >> http://lists.zeromq.org/mailman/listinfo/zeromq-dev >> >>
_______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
