Okay, fair enough. Not every use-case calls for throughput to trump latency, though, so it would be good to make that an optional feature.
On Thu, Jan 16, 2014 at 9:57 AM, Apostolis Xekoukoulotakis < [email protected]> wrote: > 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 > >
_______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
