Copying over SSH via Putty tools is slower than via WinSCP
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
- Do ACK and WIN have any influence on transfer speeds?
- 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
- 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 1:
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