Otdfbt

I'm downloading from a server and downloads are maxing out at 1.3MiB/second with FileZilla but I can start concurrent downloads and they will download at 1.3MiB/second also. So why can't I download just one file at faster than 1.3MB/s and get closer to saturate available bandwidth (~6+MB/s)?

I know that I can use some other SFTP client that supports segmented downloads such as lftp, know of other good ones that are open source?

But I still want to know what is it that limits downloading one file to just 1.3MB/s, is it some technical limitation with TCP and buffers etc or some configuration issue? I checked and for sure there's no traffic throttling enabled at all for FileZilla.

Also I tried rsync and it was worse than FileZilla/SFTP. I also tried WinSCP and it was the slowest regardless of method SCP/SFTP. So at 1.3MB/s constant transfer FileZilla is pretty good compared to the other methods of transfer.

If someone has a good explanation of why transfers peak at 1.3MB/s I'd really like to know, and if its possible to increase this without resorting to using segmented downloading. Server is running OpenSSH 6.7p1 (Debian) client is FileZilla on Windows.

UPDATE: In response to Martin's information (see his answer below) I am adding that ping is 180ms to 190ms pretty constant between server and client that is downloading. Also cpu usage is very low, 2% to 8% max.
I tried with latest version winscp 5.73 and with sftp mode I got 555kb/s and about 805kb/s max with scp mode. Whereas if I start a secondary concurrent transfer in Filezilla I get constant 1.3MiB/s for it also.

So could the 180ms delay to the server be a mathematically limiting factor as Martin and Michael touched on a bit? Or could there still be something else to blame such that I can improve the throughput? If not, I'd appreciate if anyone knows any other (like lftp but runs well on Windows) open source downloader that is secure and supports segmented downloading.

There are three common factors that affect a transfer speed:

• Bandwidth - An obvious factor that's apparently not your trouble.



• 
  

  Network delay/latency - The SFTP is packet oriented-protocol. When downloading, the SFTP client sends a "read" request to the SFTP server, waits for a response, appends returned data to a local file; and repeats, until the end of the file.

  
  
  

  Even if your connection is fast, if the server is far away (or slow), it takes a time for the data to arrive back. If the client spends this time uselessly waiting, your transfer speed will be low.

  
  
  

  Most SFTP clients (including FileZilla and WinSCP) overcome the problem by both requesting a large chunk of the file in each single "read" request and by sending (queuing) multiple "read" requests without waiting for a response to previous. For example WinSCP can request up to 32 chunks for 32 KB each at once, totaling 1 MB (these are defaults). But if there's a big discrepancy between the bandwidth and the network delay, even that 1 MB can be too small to saturate the bandwidth.

  
  
  

  An underlying TCP protocol can suffer a similar problem. So it's not only how the actual SFTP client is efficient, but also how an underlying TCP layer is efficient.

  
  
  

  See also Bandwidth-delay product on Wikipedia.

  
  
  

  I do not think this is your trouble either, at least if you have used the latest version of WinSCP for the tests. There have been some improvements in the recent releases, which allow WinSCP to utilize high-latency connections as efficiently as FileZilla.

  
  


• 
  

  CPU - The SFTP, being encrypted, is CPU intensive. If you have a relatively slow CPU, comparing to a large bandwidth, the transfer can be capped by your CPU being unable to encrypt (or decrypt in case of the download) the data as fast as your network is capable of transferring them.

  
  
  

  Common SFTP clients cannot distribute the encryption/decryption among CPU cores, so it's actually a capacity of a single CPU core that limits the transfer speed.

  
  
  

  Use the Windows Task manager to see, if one of the cores is utilized to its maximum during the transfer.

  
  

I had this issue as well.

I Used task manager to set the priority to high.

Now I get up to 5 MiB/s

I recently tried on same exact network with windows 10 and perhaps newer version of filezilla and I got up to 7MB/second transfers from the same server! I then tested with RSYNC inside a virtual machine and got 7MB/second also. I am "pretty sure" now that the problem lies with the COMODO firewall I have installed on this Windows 7 system.

Apparently even if you "disable" it, all it does is not enforce rules but it slows down network stack. I have installed/replicated this windows 7 system inside a virtual machine also and I will try to completely "remove" Comodo cis premium (antivirus+firewall) and confirm here. I should also mention on this machine I also noticed erratic intermittent latency pings to some systems on my network where all other systems between that were stable <1ms. So bandwidth delay product info is very good but in my case I was able to get filezilla and rsync both at 7MB/s (which basically saturates my available bandwidth) on another install, same network local and remote.