Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I just moved halfway across the globe and am having a strange connection issue. I have a 4 Mbps dsl connection, can successfully ssh into my server, and setup a tunnel. I use PuTTY (on my desktop - PC) and Terminal (on my mac). The speed from my desktop is getting on average 0.5 Mbps. If I test the speed direct to the closest server (ie without the proxy/tunnel) to my server however I get the 4 Mbps as advertised.

The only differences are the desktop is on a CAT5 connection and the Mac is wireless through the DSL router. I checked the cable by plugging it into the Mac and it got 4 Mbps to the tunnel. The other Ethernet connections to the router also get the 4 Mbps speed.

Below is the putty.log. I'm not sure if it is the router or the configuration of the putty connection and I'm at a loss after spending 4 hours on Google.

Any help would be appreciated. The server itself is running Ubuntu 10.04.

2011-08-01 14:14:13 Looking up host "x.x.x.x"
2011-08-01 14:14:13 Connecting to x.x.x.x port 22
2011-08-01 14:14:13 Server version: SSH-2.0-OpenSSH_5.3p1 Debian-3ubuntu7
2011-08-01 14:14:13 We claim version: SSH-2.0-PuTTY_Release_0.60
2011-08-01 14:14:13 Using SSH protocol version 2
2011-08-01 14:14:14 Doing Diffie-Hellman group exchange
2011-08-01 14:14:14 Doing Diffie-Hellman key exchange with hash SHA-256
2011-08-01 14:14:14 Host key fingerprint is:
2011-08-01 14:14:14 ssh-rsa 2048 aa:bb:cc:dd:0f:a3:1e:06:bc:c8:7d:dd:cc:bb:aa:11
2011-08-01 14:14:14 Initialised AES-256 SDCTR client->server encryption
2011-08-01 14:14:14 Initialised HMAC-SHA1 client->server MAC algorithm
2011-08-01 14:14:14 Initialised AES-256 SDCTR server->client encryption
2011-08-01 14:14:14 Initialised HMAC-SHA1 server->client MAC algorithm
2011-08-01 14:14:15 Reading private key file "C:\key.ppk"
2011-08-01 14:14:17 Offered public key
2011-08-01 14:14:18 Offer of public key accepted
2011-08-01 14:14:20 Access granted
2011-08-01 14:14:21 Opened channel for session
2011-08-01 14:14:21 Local port 1080 SOCKS dynamic forwarding
2011-08-01 14:14:21 Allocated pty (ospeed 38400bps, ispeed 38400bps)
2011-08-01 14:14:21 Started a shell/command
share|improve this question
Not sure if you're saying both the Mac and PC are slow, or just the PC? – EightBitTony Aug 1 '11 at 12:23
@EightBitTony Just the PC is slow, and only through the putty tunnel. The mac works fine. 4Mbps for all including the PC except the PC is getting the .5 Mbps when tunneled through putty. – jason Aug 1 '11 at 12:36
And the Mac gets 4Mbps through the tunnel too? If so, can you post the ssh commands used (ssh -L or ssh -D, with a -v -v on both the PC and Mac?) Ah - putty and Terminal, not ssh command line, hmm, not sure if you can get logs from both. – EightBitTony Aug 1 '11 at 12:37
@EightBitTony not sure how to output the command that putty sends but here is the mac which works great: ssh -C -2 -vvv user@ip -i keyfile -D 1080 – jason Aug 1 '11 at 12:42
You use ssh -C on your Mac, did you enable compression in PuTTY as well? – Kenny Rasschaert Jan 11 '12 at 11:47

As a general rule for ssh connections/tunnels speed... Putty is single-threaded application, so even on multi-core systems you are limited by a speed of single cpu core. For high speeds, choose fast cipher - Blowfish. Either configure it in putty, or if using commandline ssh, specify ssh -c blowfish ... to use it. Using this, you will be still limited to about max. 10 MB/s on a Gbit local network.

share|improve this answer

I ran into similar issues with WinSCP (based on PuTTY's SSH implementation) over a high-latency link across the Atlantic. The way PuTTY and WinSCP would handle its network buffers would not allow TCP window scaling to do its job, which is really necessary for high-latency links. It would always send two packets, one large and one small. The first would have a payload of 1460 bytes and the second would have 76 bytes.

This thread has a very good explanation as to why 1460+76 bytes is significant.

In any case, I solved this problem for myself by ditching PuTTY/WinSCP in favor of Bitvise Tunnilier, which does not exhibit this kind of buffering/window scaling issue.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.