In this particular test, there is only ever one message, so queuing isn't the issue here.
On Thu, Jan 16, 2014 at 10:16 AM, Apostolis Xekoukoulotakis < [email protected]> wrote: > From what Martin Sustrik writes, batching happens only when there is need > for a queue and it should in fact help the queue become smaller and thus > reduce latency. But batching itselfs adds some latency too, so you may want > to disable it. > > In my opinion, the only other option is to drop messages. > > > 2014/1/16 Lindley French <[email protected]> > >> 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 >> >> > > > -- > > > Sincerely yours, > > Apostolis Xekoukoulotakis > > > _______________________________________________ > 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
