[PATCH] Using TCP_NODELAY unconditionally

[Tobias Ringstrom]

On Sat, 19 Jan 2002, Kevin Steves wrote:

> On Sat, 19 Jan 2002, Tobias Ringstrom wrote:
> :When analyzing the performance of sftp some weeks ago, I discovered that
> :the cause of the horrible performance was the use of the Nagle algorithm
> :on the ssh TCP connection, i.e. TCP_NODELAY was not used.
> :
> :I propose that the following patch is applied, enabling TCP_NODELAY for
> :both ssh and sshd, unconditionally.  Since the SSH channel is packet
> :bases, if we want to reduce the amount of data on the wire, we should use
> :a Nagle-type algorithm before making packets of the data.  It is more
> :efficient to make one SSH packet of two small data "chunks" than to make
> :two packets of the data chunks, even if both fit within one TCP packet.
> 
> can you provide some tcpdump traces to show nagle delays during sftp?

I suppose I could, but why exactly?  Are you looking for proof that it is
Nagle that is indeed the performance killer?  It is easy to theoretically
show how Nagle kills performance when you have a request-reply packet
based protocol.  For example, when writing data to the server, the server
replies with a small response packet (tens of bytes).  This response
packet will not be transmitted immediately because of the Nagle algorithm
is waiting for more data to form a full packet.  Since the client is
waiting for the response before sending another write packet, performance
drops radically, especially over a fast link.  Overlapping requests helps
a bit, but if your link is very fast, you need many overlapping requests.

It is also easy to show it by transmitting a file over a high-speed
network with and without TCP_NODELAY.  Without it, both the server and the
client are mostly idle, and the network is not fully utilized.

The empirical results may of course depend on the OS's Nagle
implementation.  I'm using Linux 2.4.17 on both ends.

Please let me know if you still want a tcpdump!  I cannot produce one
right now because one of my computers is busy, and I need to sleep.

/Tobias