[clug] Diagnosing SSH performance problems [SEC=UNCLASSIFIED]
scudette at gmail.com
Thu Dec 10 15:16:14 MST 2009
The problem occurs frequently enough to even be documented on wikipedia
It is not related to noise or saturation and has nothing to do with
window scaling - usually just an incorrectly configured firewall.
On Thu, Dec 10, 2009 at 10:59 PM, Daniel Pittman <daniel at rimspace.net> wrote:
> Michael Cohen <scudette at gmail.com> writes:
>> What you describes sounds like your machine is configured for too high an
>> MTU for the link.
> Are you assuming a noisy link, such as an analog modem without error
> correction, or something like that?
> Otherwise incorrect MTU settings should result in either PMTU discovery, or a
> stall as the client sends over-large packets, and those packets are never
>> Try to lower your MTU and see if that fixes it. If that is the issue ensure
>> your firewall does not block ICMP MTU discovery type messages so that your
>> system is able to discover the appropriate MTU.
> Mmmm. At the network layer, I would more suspect a firewall that strips the
> window scaling option, and a Linux that sets window_scale to 2 so that the
> connection limps along rather than stalling forever.
> Alternately, something else such as high packet loss or latency on the link
> might show these results; it could also be asymmetric load, with one direction
> close to saturation, resulting in high latency in one direction only.
>> On Thu, Dec 10, 2009 at 5:18 PM, Roppola, Antti - BRS
>> <Antti.Roppola at daff.gov.au> wrote:
>>> Hi all,
>>> So I have an SSH problem where pushing data over an SSH connation gets
>>> me less than 9600 baud and numerous halts and timeouts. Pulling from the
>>> same host just rips along as you'd expect.
>>> Nothing obvious seen using "ssh -v". Nothing relevant leaps out at me in
>>> To me this suggests the issue is deeper down in the transport, network,
>>> data link of physical layer. Viz, I can't think of anything in OpenSSH
>>> that could be mis-configured to give asymmetric symptoms.
>>> Does this seem like a reasonable hypothesis?
> Yes, to me. I can't really envision a scenario that results in asymmetric
> behaviour when *only* OpenSSH is responsible.
>  When the option was first introduced, this was set to 7, resulting in
> effectively a zero window when the option was stripped; now it default
> to 2 by default, and provides bad-but-functional connectivity.
>  When you only send acks from your machine to theirs, performance stays
> good. When you send bulk data, however, you are exposed to the
> transmission delays.
> ✣ Daniel Pittman ✉ daniel at rimspace.net ☎ +61 401 155 707
> ♽ made with 100 percent post-consumer electrons
> linux mailing list
> linux at lists.samba.org
More information about the linux