On 10/25/19 12:28 AM, Jon Maloy wrote: > 1) TIPC_NODELAY might be a good option, although I fear people might misuse > it in the belief that TIPC nagle has the same disadvantages as TCP nagle, > which it doesn't. > But ok, I'll add it. > > 2) CONN_PROBE/CONN_PROBE_REPLY are not considered simply because they are so > rare (once per hour) that they won't make any difference. > > 3) We don't really have any tools to measure this. The latency measurement in > our benchmark tool never trigs nagle mode, so we won't notice any difference. > When nagle is enabled, we can only measure latency per direction, not > round-trip delay (since there is no return message), but logically it works > as follows: > > Scenario 1: > 1) Socket goes to nagle mode. The message trigging this is not bundled, > but just sent out with the 'response_req' bit set. > 2) A number of messages and possible skbs are added to the queue. > 3) The ACK_MSG (response on msg 1) arrives after 1 RTT, and the > accumulated messages are sent. So, the first message, probably added just > after the 'resp-req' message was sent might have a delay of up to one RTT. > The remaining messages in the queue will have a lower delay, and notably a > message added just before the ACK_MSG arrives will have almost no delay. > > Scenario 2: > 1) Socket is in nagle mode, and a number of messages are being > accumulated. The last message in the queue always have the resp_req bit set. > 2) The queue surpasses 64 k, or a larger message than 'maxnagle'is being > sent. So the whole send queue is sent out. > 3) Obviously we didn't wait for the expected MSG_ACK in this case, so > the delay for all messages is less than 1 RTT. > > Remains to know the size of RTT, but in the type of clusters we are running > this is rarely more than a few milliseconds, at most. This in contrast to > TCP, where the delay may be several hundred milliseconds. >
Thank you for your clear explanation. It makes me fully understood why you stated the delay was no more than one RTT after nagle was enabled. _______________________________________________ tipc-discussion mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/tipc-discussion
