[PATCH] Using TCP_NODELAY unconditionally

Tobias Ringstrom tori at ringstrom.mine.nu
Tue Jan 22 09:03:49 EST 2002


On Mon, 21 Jan 2002, Rick Jones wrote:

> The way the Nagle algorithm is supposed to work is like this:
> On every user send the code is supposed to go through this sequence of
> pseudo logic:
> 1) is the quantity of data in this send, plus any queued unsent data
> more than the MSS for the connection? if yes, send the data now
> (modulo other constraints such as receiver window and congestion
> window) if no, go to 2.
> 2) is the connection otherwise "idle"? that is, do we have no
> unacknowledged data outstanding to the remote? if yes, send the data
> now, if no, queue the data and wait.

You are right of course.  Thanks for straightening this out!

This is getting funnier all the time.  The reason why the Nagle algorithm
triggers is probably because of the SSH2_MSG_CHANNEL_WINDOW_ADJUST
messages.  Every fourth SSH2_FXP_READ message, a window adjust message is
sent, and the two messages are sent with two write calls.  Both messages
are short, and one of the packets will be held back by the Nagle
algorithm.  The window adjust message seems to be sent before the read
message, which delays the read until Nagle times out, which in turn
explains the bad performance, at least part of it.

Looking once more at the tcpdump, I can clearly see the Nagle algorithm 
at work.  (48 byte is win_ad, 64 byte is sftp read request)

22:42:47.141152 boris.ssh > igor.32784: P 17776:17824(48) ack 1439097 win 63712 <nop,nop,timestamp 1258913 309706> (DF) [tos 0x8] 
22:42:47.171611 igor.32784 > boris.ssh: . ack 17824 win 10880 <nop,nop,timestamp 309710 1258913> (DF) [tos 0x8] 
22:42:47.171773 boris.ssh > igor.32784: P 17824:17888(64) ack 1439097 win 63712 <nop,nop,timestamp 1258916 309710> (DF) [tos 0x8] 

Merging the two messages into one write would make sftp not trigger the
Nagle algorithm, but it would not help the X11 forwarding case, which
really needs TCP_NODELAY.

Ahhh, progress...

/Tobias




More information about the openssh-unix-dev mailing list