[clug] Diagnosing SSH performance problems [SEC=UNCLASSIFIED]

[Daniel Pittman]

Craig Small <csmall at enc.com.au> writes:
> On Thu, Dec 10, 2009 at 10:59:12PM +1100, Daniel Pittman 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?
>
> Crummy wireless/WiFi links look something like that too; but then the bulk
> transfer would suffer as well.

Hmmm.  I thought most 802.11g equipment was reactive, and would fragment or
reduce MTU in the face of noise.  I presume I must have imagined that, though;
I certainly have no actual evidence to support my belief.

> To me a MTU problem would hurt bulk transfers way more. You see MTU type
> problems where you can login fine or type simple commands, but the moment
> you run top or ls -lR it locks up.

*nod*  Those are the symptoms I would expect for a PMTU black hole or
equivalent, but not so much for an asymmetric performance drop as described.


Which reminds me: I was making the assumption that pushing to the server
(slow) meant "client initiates TCP connection", and pulling from the server
(fast) meant "server initiates TCP connection" in my comments.

Which, if both initiate from the same side, strongly suggests that it isn't a
firewall stripping the TCP window scaling options or anything.

> Could you turn on something temporary like tcp echo to see if it is the
> interactive part that is causing the problems or ssh itself?

I am very fond of 'mtr' for showing performance across a link like this; it
shows you a combination of traceroute and ping, and can make it very obvious
where your problem sits.

(No idea if it helps the OP, though.)

        Daniel

-- 
✣ Daniel Pittman            ✉ daniel at rimspace.net            ☎ +61 401 155 707
               ♽ made with 100 percent post-consumer electrons