I have got a 300mbit symmetrical fiberoptic line, and I have got to transfer a 51MBYTE tar file from HOST A (fiberoptic 300mbit) to HOST B (digitalocean machine with more than gigabit bandwith).

On both side I have got nice speedtests results (300mbit on A, 700 on B) but when I scp from A to B I have got this:

assets.tar            100%   51MB 220.3KB/s   03:55

only 220kbit of maximium speed.

But if I do from HOST B to A I have got a really nice result:

assets.tar            100%   51MB   8.4MB/s   00:06    ***REALLY GOOD SPEED***

What can be the issue?

  • What if you try with some speed limit like scp -l 200000 ? Check if this helps.
    – coffeMug
    Jun 9 '16 at 18:39
  • Is A your home box? in this case 300 mbit/s is download speed only. To save some money many internet providers limit upload speed.
    – Putnik
    Jun 10 '16 at 8:32
  • You are muddling your Bytes ("B") and bits ("b"). For example, "when I scp from A to B i have got [...] only 220kbit of maximium speed". The 220KB/s is 2.2Mbit/s.
    – roaima
    Jun 11 '16 at 7:35

SCP is very simple tool to simple copy files back and forth. It was not designed to super-fast speeds and it has really small buffers on both sides.

If you aim for performance, you should use sftp or rsync.

About the speed measures, lets draw some diagram:

[host A]   --- ??? mbit  ---    [host B]
        \                      /
         \ 300 mbit           / 700 mbit
          \                  /
           [speedtest server]

The data between two hosts does not have to go through the speedtest server you measured the speed against (and they probably don't go) so these measures are irrelevant for your case. If you want to measure speed between these two hosts, you really need to measure traffic between these two and not anything else. There might be some line that is assymetric or different way limited.

  • ISTR that today's OpenSSH uses sftp under the covers for the scp command.
    – slim
    Jun 11 '16 at 6:06
  • @slim, no, it does not. Check the source.
    – Jakuje
    Jun 11 '16 at 7:11
  • I'm certain I've seen systems where /usr/bin/scp is a symlink to /usr/bin/sftp (and sftp handles parmams differently if argv[0] is scp). However the source you've linked doesn't confirm that, and nor does the Raspbian system that is the only Linux I can reach right now.
    – slim
    Jun 11 '16 at 7:32
  • I have never seen such system. They have different synopsis, so you can't symlink them without confusing a lot of users. Also they use different way to handle the server side (subsystem x just command).
    – Jakuje
    Jun 11 '16 at 7:36
  • Not sure what you mean there. ls and cat have different synopsis, but on some systems both are symlinks to busybox and most users don't even notice.
    – slim
    Jun 11 '16 at 7:54

I would start by measuring the speed of the dumbest TCP stream possible. A plain FTP (not SFTP or FTPS) would do it. If for some reason FTP doesn't work (firewalls can be an issue), try netcat.

FTP just literally throws bytes at a socket. As long as it's using the full TCP packet size, and we're talking about a single file, you can't use TCP more efficiently. So this will give you a benchmark of what can be achieved between the two hosts.

(There are some UDP-based protocols that can go faster over WAN by avoiding the wait for TCP ACK packets, but none of these is a commonly used standard).

Note, however, that FTP does not compress, so it may take longer for certain kinds of data. This is good for our aim of measuring raw TCP throughput.

If FTP is slow/asymmetric too, then it may just be that there's an asymmetric link along the route between these machines. You could do some further diagnosis by running a Wireshark sniffer on both ends, and checking the trace for lost packets etc.

If FTP is fast and symmetrical, then you have some other problem. Without delving in deep, it's hard to guess, and there's a lot of possibilities. For example, one machine's SSH might be configured to compress while the other is not.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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