Date: Sat, 1 Dec 2001 17:32:40 +0100 From: Tomas Svensson <tsn@gbdev.net> To: Matthew Dillon <dillon@apollo.backplane.com> Cc: Josef Karthauser <joe@tao.org.uk>, freebsd-hackers@FreeBSD.ORG Subject: Re: SSH stalls (was: FreeBSD performing worse than Linux?) Message-ID: <20011201173240.A20807@simba.systemteknik.net>
next in thread | raw e-mail | index | archive | help
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. -Tomas MD> I haven't been able to reproduce this. Two things, though... (1) are MD> you using a compressed ssh connection or an uncompressed connection? MD> It makes a big difference in regards to how ssh generates packet data. MD> 'ls' contains a lot of repetitive data and compresses well. MD> (2) Also are you using an xterm or an aterm? aterm will skip terminal MD> data until the flow stops if it receives it quickly enough, not displaying MD> anything until it 'hicups' at the end. xterm will sync the display up MD> every so often when receiving a continuous stream. So if you are using MD> aterm it could appear as though the connection has stalled when, in fact, MD> it is actually running full bore and aterm is waiting for things to slow MD> down. MD> For example, when I run a program that spits out abcdefgh...zabcdefgh... MD> etc to the terminal, and run it on an aterm, it seems to stall every MD> so often. But if I run it on an xterm the output appears smooth. MD> -Matt :JK>> Is this the same problem that I experience on ssh connections between :JK>> my 5.0-current laptop and my releng_4 server? When I run an 'ls' :JK>> from the shell on large directories I get the response back block :JK>> delay block delay block. I assumed that it was a problem with :JK>> -current. MD> : MD> :I am quite sure that this is a problem introduced in OpenSSH v2.5 or MD> :earlier. When I upgraded a FreeBSD 4.2 box from OpenSSH v2.2.0 to a MD> :newer version (I don't remember exactly which one now) I noticed this MD> :stalling which had never appeared before. If I used SSH Inc ssh-2.4 MD> :there was no stalling. It's not FreeBSD-specific either: I am MD> :trying this now on a NetBSD 1.5.1 that has OpenSSH v2.5.2 and if I MD> :do ten ls -l as fast as I can, I get 14 retransmitted packets and MD> :stalling. If I try the same with SSH Inc ssh-3.0.0 I get no MD> :retransmitted packets. Strangely enough I get no stalling on either MD> :sshd if I cat a 3 megabyte text... MD> : MD> :-Tomas To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20011201173240.A20807>