> I am not using compression and netstat -s confirms that it is really > resending data. I examined it a bit more now and it seems OpenSSH 2.5 is > sending a burst of small packets, each with 100 or 116 bytes > > 14:30:46.232151 server.22 > client.1525: P 30977:31077(100) ack 1144 win 24820 > 14:30:46.233358 server.22 > client.1525: P 31077:31177(100) ack 1144 win 24820 > > and another 50 small packets just like them rapidly after eachother. > After this it will start to send bigger packets, 1076 or 1460 but its too > late and its likely that the server will have to resend part of the small > packets and connection will stall. This won't be a problem on a LAN but > over the internet it can be. SSH Inc sshd doesn't have this problem as it > always send 1460 bytes per packet when possible. I have not been able to > reproduce this with OpenSSH 2.3.0 because it seems to send 276-300 bytes > per packet.
This might be because our OpenSSH disables Nagle's algorithm by turning on the TCP_NODELAY socket option. See packet.c:packet_set_interactive() for the code that does this. This certainly will cause a bunch of small TCP segments to be generated, back-to-back before an TCP ACK is received. It's also probably a bad idea to enable by default for every SSH interactive session. It looks like this gets turned on for X11 connection forwarding and for SSH sessions with a PTY at the server end. louie To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
