Slow SSH between desktop and server

[gdi2k]

I have a dedicated server to which I connect from my desktop machine via ssh. Normally it's just console stuff, but occasionally I do need to download stuff from it. If I do this using its webserver, I max out my (rather slim) DSL connection at 60 kb/sec. But if I connect using ssh, and download stuff through the tunnel, it's unbearably slow (around 3kb/sec). My ssh experience is limited - is that normal? Because of the encryption maybe? Or the latency?

Neither my desktop nor the server are underpowered (server's an Athlon XP 1,7 GHz, 768 MB Ram & desktop's an Athlon64 2 GHz, 512 MB Ram). My Ping to the server averages around 380 ms with no serious packet loss. I'm using Fedora Core 1 on the server (don't ask), and of course gentoo on the desktop, and I haven't changed ssh configs on either of them much, so they're pretty standard.

I'm not really sure where to start looking as to where the problem might be, or if there even is a problem - maybe my expectations for data transfer over ssh are too high?

Thanks,

GDI

[adaptr]

It's true that SCP (file transfer over SSH) is usually slower than any other form of transfer, but it shouldn't be that slow.

On the other hand, 380ms ping times ? That is just plain sad...
I get 10 ms outgoing responses from my ADSL line at home, and around 30ms from the Internet to my home servers - over that same ADSL line.

It looks there is a bottleneck somewhere, alright - have you compared the ssh/sshd versions ?
_________________
>>> emerge (3 of 7) mcse/70-293 to /
Essential tools: gentoolkit eix profuse screen

[gdi2k]

Yeh, my slow ping is due to the fact that I'm pretty much exactly on the other side of the world to my server.

My ssh versions are:
Desktop: OpenSSH_3.9p1, OpenSSL 0.9.7e 25 Oct 2004
Server: OpenSSH_3.6.1p2, SSH protocols 1.5/2.0, OpenSSL 0x0090701f

The server's SSh might be worth upgrading, but it's a real hassle with fedora (I hope to plaster gentoo over it soon! )

Do you think the miserable ping is the culprit?

[adaptr]

Either that, or in combination with other network latency factors.
Does downloading etc. work okay normally ?
If it never works right it may be an MTU issue, but that's unlikely on a dedicated server.

Try testing SFTP if you can get it to work on FC.
_________________
>>> emerge (3 of 7) mcse/70-293 to /
Essential tools: gentoolkit eix profuse screen

[gdi2k]

Well, it's odd: If I use standard FTP to download from the server, the speed sucks just as much (around 3 kb/sec). Yet downloading via HTTP I max out my connection.

I've had a friend in another country test it for me, and he gets full download rates whether FTP or HTTP. So it's not the server.

I can only think that it's to do with the proxies here in the UAE (yes, the web is censored here ). Maybe they use different proxies for different protocols or something? Can't think why that would make sense, but can't come up with any other explanation either.

[adaptr]

Well, let's see... hmmm..

FTP == downloading pr0n, so FTP bad, mm'kay ?
SSH == control over complex systems, so SSH bad too, mmm'kay ?
HTTP = filtered through nationwide fascist proxies, so state-sanctioned HHTP good, mmm'kay ?

Not that hard to figure out...

It might have been easier if you just supplied this kind of information right at the start - how the fsck should I have known all that ?
_________________
>>> emerge (3 of 7) mcse/70-293 to /
Essential tools: gentoolkit eix profuse screen

[gdi2k]

I didn't post the fact the web is proxied here, because I didn't think it would be to do with that. And I still don't.

I can max out my connection downloading via FTP from sites that are either geographically close (but still the other side of the proxies), and from larger sites that make use of content delivery networks. P2P networks work very fast too, so I don't think the proxies are doing much in the way of non-web-content filtering/monitoring.

I can only think it has do with high latency: About.com says "Whereas theoretical peak bandwidth is fixed, actual or effective bandwidth varies and can be affected by high latencies. Too much latency in too short a period of time can create a bottleneck that prevents data from "filling the pipe," thus decreasing effective bandwidth."

Why would SSH be affected, but not HTTP? (afterall, they both run on top of TCP)
Because: "Some applications (ssh and scp, for example) implement internal flow control using an application level window mechanism. This internal flow control window effectively defeats TCP tuning."

mmm'kay ?

EDIT: This still doesn't explain why my FTP speeds suck, but my HTTP speeds are fine, from the same server. Grumble.

[kar1107]

Thats strange.. I'm curious if you found a fix or reason

True, all apps run on TCP -- so its flow control has to be seen on ftp/http too.

I was thinking that the ISPs can give different QoS for interactive (http) apps and non-interactive (ftp). But scp goes over tcp and port-22, which should be treated as interactive. Hence that doesn't explain the delay.

Can you isolate the issue on client side. Use a different ssh/scp client -- how about from windows? Then try a difference close by server. If you can eliminate the problem, then we can take the network/ISP/middle-man out of the picture.

I doubt any flow-control done by app is an issue here -- usually a single pkt drop affects TCP windowing soo much that your tcp throughput can plummet.

[Mad Merlin]

Many Universities, ISPs, large businesses and anybody else sharing a (?:ph|f)at pipe to a large number of individuals will use packet shaping or something similar, in that they will inspect all packets that pass through and slow down the flow of selected protocals such as P2P and FTP so that their bandwidth isn't totally saturated by a few people running bittorrent. HTTP is often allowed to reign free, which would explain that part of it as well. Basically, it's probably something beyond your control though.

In a side note, I find that scp is usually *much* faster than SMB or FTP, mainly due to the compression. In my own informal testing and usage, I can get anywhere from 10 to 13 megabytes/second over a 100 mbit LAN using scp, but only about 5-6 megabytes/second using SMB, scp does use significantly more processor time though, YMMV.