openssh unix dev - May 2013 - ssh ethernet tunnel performance problem

Hi

(I'm not subscribed, please, cc)

I've got an ethernet level ssh tunnel to a remote system. That system is 
running a terminal server, so, that tunnel is the only connection, I've 
got. The terminal server is connected via a serial and an ethernet cable 
to a test board and is configured to bridge that ethernet connection to my 
tunnel. I can then trigger that test board to start a TFTP or NFS data 
transfer over the tunnel from my system. The whole should look like this:

[my client] --- <internet> --- [terminal] === <serial cable> ===
[test ]
                               [ server ] ----- <ethernet> ----- [board]

(whereas I don't know whether the terminal server actually has 2 ethernet 
interfaces or only 1. I think, it should really have 2 at least, because 
actually it's serving 8 test boards, I'll try to clarify its 
configuration and post an update)

This works in principle, and from a "geographically close" location
also
runs reasonably quickly. Whereas from my half-world distance I'm getting 
like 1.5kBps tftp and a bit more with NFS. The person, who's set up the 
server says, that he previously also had performance problems with an 
older Fedora distro, but with Fedora 18 it runs fast now. I've tried with 
Debian squeeze with a self-build 3.9.1 and (about 1-2 year old) Ubuntu 
both over my and a 3G connection - the speed remains the same. Any clues?

Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/

On Thu, May 09, 2013 at 06:23:24PM +0200, Guennadi Liakhovetski
wrote:
> Hi
> 
> (I'm not subscribed, please, cc)
> 
> I've got an ethernet level ssh tunnel to a remote system. That system
is
> running a terminal server, so, that tunnel is the only connection, I've
> got. The terminal server is connected via a serial and an ethernet cable 
> to a test board and is configured to bridge that ethernet connection to my 
> tunnel. I can then trigger that test board to start a TFTP or NFS data 
> transfer over the tunnel from my system. The whole should look like this:
> 
> [my client] --- <internet> --- [terminal] === <serial cable>
=== [test ]
>                                [ server ] ----- <ethernet> -----
[board]
> 
> (whereas I don't know whether the terminal server actually has 2
ethernet
> interfaces or only 1. I think, it should really have 2 at least, because 
> actually it's serving 8 test boards, I'll try to clarify its 
> configuration and post an update)
> 
> This works in principle, and from a "geographically close"
location also
> runs reasonably quickly. Whereas from my half-world distance I'm
getting
> like 1.5kBps tftp and a bit more with NFS.
Based on the version and presumably latency I'd guess the reason is
the small default channel window size in older versions of OpenSSH.
You fill the channel window up and since you have a high-latency are
then blocked until it drains.  That'd explain why it works ok when
you're close.

The channel window size used to be (I think) 64k but was changed to
2M several years ago.  You can check this by running ssh -vvv and look
for this:

debug2: channel 0: rcvd adjust 2097152

(You should also see the same thing on the server side)
> The person, who's set up the 
> server says, that he previously also had performance problems with an 
> older Fedora distro, but with Fedora 18 it runs fast now. I've tried
with
> Debian squeeze with a self-build 3.9.1 and (about 1-2 year old) Ubuntu 
You mean OpenSSH 3.9p1?  That's pretty old and before the channel window
changes.  Can you reproduce the problem with a current version (6.2p1?)

-- 
Darren Tucker (dtucker at zip.com.au)
GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4  37C9 C982 80C7 8FF4 FA69
    Good judgement comes with experience. Unfortunately, the experience
usually comes from bad judgement.