9

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
  1. 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.

Improve this question
2
  • This question is still relevant. I come to similar results when benchmarking plink (about 1 MiB/s) and winscp (about 6-9 MiB/s). You can replace plink with official OpenSSH port to Windows, see Win32-OpenSSH. It gives similar performance as winscp (solid 8 MiB/s).
    – Vlastimil Ovčáčík
    Commented Aug 12, 2017 at 8:15
  • There is github issue Slow download network speed over plink relevant to this question, with more benchmarks.
    – Vlastimil Ovčáčík
    Commented Aug 12, 2017 at 10:11

4 Answers 4

Reset to default
8

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

Improve this answer
2
  • 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.
    – BadTenMan
    Commented Apr 18, 2015 at 15:59
  • 1
    I have added details on the "TCP push" flag
    – Martin Prikryl
    Commented Apr 20, 2015 at 6:54
0

The best advises given on FAQ - WINSCP SPEED, PLUS - update the WINSCP to latest version.

quote:

When using SSH, file transfers in WinSCP are encrypted and it's CPU intensive. Blowfish is usually a lot faster than AES (so,try BLOWFISH). It may also help if you turn off compression, if you have turned it on before.

In case the speed is throttled by connection latency, it may help if you use SCP protocol instead of SFTP. SCP is less affected by latency. In this case, it may help if you turn on compression.

Improve this answer
1
  • As I commented another answer: WinSCP is fine for me. Putty's pscp is the problem.
    – BadTenMan
    Commented Jul 28, 2016 at 16:37
-1

Pscp has no -c switch to select a cipher like scp on *nix. To get around this you can save your destination host as a putty session, which allows you to change the cipher selection order. Blowfish tends give better performance than the default AES.

Improve this answer
2
  • 1
    While this may improve PuTTY performance, it does not answer the question, why PuTTY is slower than WinSCP.
    – Martin Prikryl
    Commented Apr 17, 2015 at 6:31
  • 1
    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.
    – Martin Prikryl
    Commented Apr 17, 2015 at 10:25
-2

WinSCP itself (unless they fixed in the lasts version?) is dreadfully slow compared to others, I'd recommend Filezilla over WinSCP, MUCH faster for ssh file transfers compared to winscp.

Improve this answer
2
  • 1
    WinSCP has perfect speed for me and saturates the bandwidth almost completely. SSH with Putty is slow in this case.
    – BadTenMan
    Commented Apr 18, 2015 at 15:55
  • 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
    – htfree
    Commented Apr 20, 2015 at 7:03

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .