Copying over SSH via PuTTY tools is slower than via WinSCP

Question

Uploading from my Windows PC (1) to my Ubuntu machine (2) in another city using PuTTY tools is slow.

I tested this over OpenVPN tunnel and via port forwarding to (2). It turns out that using rsync (Unison) via SSH (plink.exe) or pscp.exe is 70% slower than copying with WinSCP (SCP or SFTP) in (1)->(2) direction. Downloading has the same speeds for both.

Here are some data:

link    protocol    software  source  target  max speed (kb/s)
theoretical speed 4.5mbits      1       2       560
theoretical speed 6.0mbits      2       1       750
VPN     SFTP        pscp.exe    1       2       180 <- not ok
VPN     SFTP        pscp.exe    2       1       640
VPN     SFTP        winscp      1       2       570 <- ok
VPN     SFTP        winscp      2       1       670
PF      SFTP        pscp.exe    1       2       185 <- not ok
PF      SFTP        pscp.exe    2       1       700
PF      SFTP        winscp      1       2       600 <- ok
PF      SFTP        winscp      2       1       680

Unison has almost exactly the same speeds as pscp.

I inspected my packets via Wireshark, but there seems nothing special. Just that WinSCP sends more than twice the amount of packages in the same time.

Send-style:
WinSCP: 2 or 3 SSH1 to server, 1 back (ACK)

No.     Time           Source                Destination           Protocol Length Info
797 1.003187000    10.8.0.6              10.8.0.10             TCP      54     22?51739 [ACK] Seq=5089 Ack=496673 Win=7079 Len=0
798 1.003208000    10.8.0.10             10.8.0.6              SSH      1241   Client: Encrypted packet (len=1187)
799 1.003211000    10.8.0.10             10.8.0.6              SSH      1241   Client: Encrypted packet (len=1187)
800 1.008147000    10.8.0.6              10.8.0.10             TCP      54     22?51739 [ACK] Seq=5089 Ack=499047 Win=7079 Len=0
801 1.008166000    10.8.0.10             10.8.0.6              SSH      1241   Client: Encrypted packet (len=1187)
802 1.008180000    10.8.0.10             10.8.0.6              SSH      1241   Client: Encrypted packet (len=1187)
803 1.008357000    10.8.0.6              10.8.0.10             TCP      54     22?51739 [ACK] Seq=5089 Ack=501421 Win=7079 Len=0

pscp: 4 SSH2 to server, 2 back (ACK) and one SSH2 back

No.     Time           Source                Destination           Protocol Length Info
210 11.000452000   10.8.0.6              10.8.0.10             TCP      54     22?51744 [ACK] Seq=6178 Ack=97187 Win=185856 Len=0
211 11.005520000   10.8.0.6              10.8.0.10             TCP      54     22?51744 [ACK] Seq=6178 Ack=98989 Win=185856 Len=0
212 11.005585000   10.8.0.10             10.8.0.6              SSHv2    1241   Client: Encrypted packet (len=1187)
213 11.005589000   10.8.0.10             10.8.0.6              SSHv2    1241   Client: Encrypted packet (len=1187)
214 11.005591000   10.8.0.10             10.8.0.6              SSHv2    1241   Client: Encrypted packet (len=1187)
215 11.005592000   10.8.0.10             10.8.0.6              SSHv2    669    Client: Encrypted packet (len=615)
216 11.006578000   10.8.0.6              10.8.0.10             SSHv2    134    Server: Encrypted packet (len=80)
217 11.032385000   10.8.0.6              10.8.0.10             TCP      54     22?51744 [ACK] Seq=6258 Ack=101363 Win=185856 Len=0
218 11.037768000   10.8.0.6              10.8.0.10             TCP      54     22?51744 [ACK] Seq=6258 Ack=103165 Win=185856 Len=0

The Ubuntu machine is not providing SSH1, WinSCP has also chosen SSH2 in it's config.

Another difference is the WIN and ACK values

1. Do ACK and WIN have any influence on transfer speeds?
2. What could be causing this problem?

Edit: I tested with Cygwin and OpenSSH: same speeds as WinSCP. I made two pictures comparing WinSCP and PuTTY TCP info, these are the differences:

                   PuTTY  WinSCP
TCP Segment Len:   615    1187
TCP Push:          Set    Not set
Window size value  4014   4118
calc. Window size  16056  16472
[Bytes in flight:] 8352   91399

3. Could TCP Push flag be the reason?

Update - April 20th.

link    protocol    software  source  target  max speed (kb/s)
cVPN    SFTP        pscp.exe    3       4       250 <- not ok
cVPN    SFTP        winscp      3       4       580 <- ok
cLAN    SFTP        pscp.exe    3       4       10200 <- maybe not ok
cLAN    SFTP        winscp      3       4       11500 <- as expected

cVPN=commercialVPN at my home Lan, cLAN=my Office Lan, (3)->(4)=copy from office laptop to datacenter server. Here pscp also has a lower speed than winscp!

The packet order for pscp is too simple. After inspecting packets, the style is more like

...
8  client data (100% fill)
9  client data (100%)
10 client data (60%)
11 server data?
12 server ACK to packet #1
13 server ACK to packet #3
14 client ACK to packet #11
...

This is very steady. WinSCP instead does ACKs for much older packets, thus generating more packets in flight and higher throughput, as it seems not to wait for an ACK until sending the next packets.

It seems that this is somehow caused by PuTTY waiting for the ACK instead of just sending some more packets (what WinSCP does).

Other tests:

ctcp (de)activated - no change
rtt to ack winscp = 100ms
irtt winscp no info
rtt to ack pscp   = 50ms
irtt pscp = 40ms
winscp: window scaling status: unknown (-1)
pscp:   window scaling status: disabled(-2)

I would be happy to test more, but don't know what to test, try and monitor.

Solution

WinSCP uses PuTTY code internally. So there should not be any difference in an encryption algorithm selected.

Though WinSCP employs some optimizations on top of the PuTTY code, particularly larger internal and network buffers. That helps in certain cases to achieve a better throughput.

Some references:
https://winscp.net/tracker/615
https://winscp.net/tracker/690
https://winscp.net/tracker/1273
https://winscp.net/tracker/1295

---

Regarding the "TCP Push" flag:

This is likely because WinSCP disables Nagle's algorithm on the socket, while PuTTY transfer tools do not (PuTTY itself does).

I'd hope that on any reasonable network, this should not make any difference, as both application push data to the socket as quick as possible, so the network layer should have no reason to delay packets. And I definitely do not see any difference any network at tested this. But I have reports from some users that it makes a difference.

While you can toggle Nagle's algorithm in PuTTY terminal configuration, you cannot toggle it in PuTTY transfer tools (psftp and pscp), it's always enabled.
https://the.earth.li/~sgtatham/putty/latest/htmldoc/Chapter4.html#config-nodelay

Comments

[Admin]

There is github issue Slow download network speed over plink relevant to this question, with more benchmarks.

[Martin Prikryl]

While this may improve PuTTY performance, it does not answer the question, why PuTTY is slower than WinSCP.

[Martin Prikryl]

Actually it won't improve PuTTY performance in this particular case. It would, if throughput was CPU-bound. But in this case it's network-bound. In CPU-bound cases, WinSCP does not outperform PuTTY.

[BadTenMan]

WinSCP has perfect speed for me and saturates the bandwidth almost completely. SSH with Putty is slow in this case.

[BadTenMan]

Thanks for this answer! I tried to solve it like in bug 690 with registry entries for AFD and tcpip, but that does not help. I updated the question with tcp packet properties of packets (2)->(1). On Monday I will test this with one of our datacenter servers, but I don't think I am allowed to record the packets like I did here.

[Martin Prikryl]

I have added details on the "TCP push" flag

[htfree]

I was using WinSCP 4.36 on Windows 7 and it categorically was dreadfully slow compared to Filezilla, there's plenty of discussions on the web and even Bugs filed about the slowness, here's one of them winscp.net/tracker/show_bug.cgi?id=164 and here is one discussion winscp.net/forum/viewtopic.php?t=5096

[BadTenMan]

As I commented another answer: WinSCP is fine for me. Putty's pscp is the problem.