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?
SCP is based on SSH. And SSH itself has some overhead:
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.
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.
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.
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).
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:
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.
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.
