I'm just copying a bunch of files from a RaspPi 3 to my laptop using scp over an Ethernet connection. The speed is abysmal, around 0.5 to 0.6 MB/sec. Is this normal? I read somewhere that with 10/100 Ethernet you should get something like 12 MB/sec. Is the micro-SD card the bottle-neck here?

enter image description here

6 Answers 6


SCP is based on SSH. And SSH itself has some overhead: wiki

SCP is really naive protocol with really naive algorithm for transferring a few of small files. It has a lot of synchronization (RTT - Round Trip Time) and small buffers (basically 2048 B -- source).

If you want performance, use sftp. SFTP is more advanced and more ready for transferring files. It has bigger buffers which decreases need for synchronization and increases speed. I guess you would achieve similar results with rsync, which is probably the most appropriate tool to transfer data. Buffer has by default 32 768 B = 32 kB, but it is configured on command-line using -B switch.

Original answer on Unix.SE


I found a similar question/answer over at unix.stackexchange.com. Basically the bottle-neck is the encryption, and the two solutions are either to use a 'cheap' cipher or a different program for copying such as rcp.

  • 1
    I'd still say it is odd. I get transfer times of 3-6 MB/s over ethernet using scp or sshfs (I much prefer the latter though, which is sftp based), no special cipher. The fastest I've seen a pi sustain sans encryption is ~10 MB/s.
    – goldilocks
    Commented Jul 12, 2016 at 21:05
  • 1
    Not completely. The fault is the protocol itself. SCP is not made for performance.
    – Jakuje
    Commented Jul 12, 2016 at 21:06
  • @goldilocks 10 MB/s is about as fast as the Raspberry network port can transport data. These days ssh on a modern x64 CPU can utilize hardware encryption making it easy to saturate a gigabit connection. The Raspberry does not have this unfortunately. Run top in a parallel session to see if the cpu is fully used by ssh - if yes, it is the encryption. Commented Jan 6, 2019 at 2:09

Argh, don't use ssh for LAN data transfer. In a shell, cd to the directory that contains your files, and invoke python -m SimpleHTTPServer 31415 - then mirror that from your laptop at http://pi_ip:31415 .

Didn't notice you were just copying on LAN. Across internet, you should use compression, ssh uses gzip/zlib, it doesn't lag the processor noticeably.


Actually a better solution is to use rsync.

This is assuming your laptop supports it (all Linux and OS X do), and it suits your problem. rsync, as its name implies is good at keeping directories in synch, and only copies needed changes.

  • 1
    Most informal uses of rsync are done over ssh so would still incur the overheads of using ssh. You can tweak the ssh used by rsync with the latter's -e command-line option (the exception is when rsync uses its own protocol to connect directly to a remote rsync server daemon without using ssh but that requires the remote end to have been configured with a server daemon).
    – starfry
    Commented Aug 26, 2016 at 10:33

The theoretical maximum for the ethernet interface is 12.5MiB/s (100Mib / 8 bits) - that's Megabytes per second. However, the Pi is somewhat bound by the fact that the network goes through the USB interface. As other answers suggest, you can probably get more improvements by not using ssh but, if you need to use it, then you can apply some command-line arguments to make it a bit faster:

1. Don't compress

There's no point in compressing across the LAN, but old habits die hard and many people do it without thinking. Remove the compression and the performance is a more reasonable 1.86MiB/s. But that can be improved upon.

2. Use a weak cipher

You can't disable encryption with ssh but you can minimise its impact by using a weak cipher. Try the command with -c arcfour,blowfish-cbc.

You can read my original post on the Raspberry Pi Forum.


Either use an FTP service which only allows access by an unprivileged user ( certainly not sudo's NOPASSWD ) or netcat. On the receiving end do: nc -v -l 9999 | tar -xvf - -C /tmp, and on the sending side do tar -cvf - dir1 file1 dir2 file2 etc | nc -v yourPiIPHere 9999. My old pi1b+ would use 100% cpu with scp. If you must, super-compress the archive with 'dd if=archive.tar bs=512M | xz -e9vfc > archive.tar.xz' and scp that over. Use tar -Jxvf archive.tar.xz to unpack it.

  • This runs at 2.7 mb/sec from my OSX to Rasperry Pi 3 Commented Jan 19, 2017 at 23:38
  • The ethernet chip is shared with other devices on the USB bus. Could be your problem.
    – user400344
    Commented Jan 31, 2017 at 12:35

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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