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
