Dr Ed Brambley's Miscellaneous Projects (2024)

This page documents rough and ready speed tests I performed to investigate how best to copy files between two Linux computers across a fast network. The conclusions are that scp and rsync leave a lot to be desired, that sshfs and sftp are the slowest of the bunch by a factor of up to 16 for lots of small files, and that up to 8 times times faster transfers than with scp can be obtained using tar over ssh while still retaining a secure connection.

For details of the newer tests which are not limited by hard drive speed, please see below.

Details of the older tests

Tests were performed transferring data between two computers running Ubuntu 10.04.4 LTS (Lucid Lynx). The two computers contained dual core Intel Pentium D 3.2GHz processors and 4GB of memory, and were connected using Intel pro/1000 ethernet adaptors over a gigabit ethernet connection through an old but high performance Cisco switch. The hard drive on each machine had a write speed of approximately 50MB/s; this is rather slow, and so efficient nonblocking and buffering will be an important feature of these speed tests.

Two data sets were tested. An incompressible data set consisted of 200 files each of 10MB of random data from /dev/urandom. A compressible data set consisted of the uncompressed GCC4.6.3 source tree (610MB).

All measurements are given as average±standard deviation, where standard deviation is not provided if it is zero to the stated precision. These measurements are taken from a number (usually 5) of independent transfers.

Several methods of transfer were considered. These are listed below for transferring from src to dest on computer remote:

scp

scp -r src remote:dest

rsync

rsync -r src remote:dest, using rsync version 3.0.7 protocol version 30.

tar over ssh

tar -cf- src | ssh -q remote tar -xf- -Cdest

tar over netcat

ssh -f remote "nc -l 7111 | tar -xf- -Cdest" ; tar -cf- src | nc remote 7111. This in fact suffered some problems with ssh not backgrounding properly and netcat not correctly listening or correctly parsing end of file codes.

sshfs

sshfs remote:dest mnt ; cp -r src mnt ; fusermount -u mnt, using sshfs version 2.2, fuse library version 2.8.1, and fuse kernel interface version 7.12.

In all cases, the version of ssh used was OpenSSH_5.3p1 Debian-3ubuntu7, OpenSSL 0.9.8k 25 Mar 2009, and the version of (GNU) tar used was 1.22. All tests were run using the default options unless specified. For the version of ssh used, the default cipher is aes128-ctr and the default MAC is hmac-md5.

Initial tests and ssh ciphers

The first tests aimed to find the fastest ssh ciphers and compare them with the other methods. All tests in here are on incompressible data.

I conclude that:

1. tar over either ssh or netcat are far faster than the other methods, possibly because tar and the transfer run in parallel, getting around the hard disk speed bottleneck.
2. arcfour is the fastest cipher, and aes128-cbc is faster than the default aes128-ctr. Note that blowfish-cbc is not particularly fast.
3. ssh is faster than netcat using either the aes128-cbc or arcfour ciphers.

ssh Message Authentication Codes (MACs)

The second tests aimed to find the fastest ssh Message Authentication Codes (MACs) and compare them with the other methods. All tests here are on incompressible data using the arcfour cipher found above to be the fastest in this case.

I conclude that:

1. For the scp and rsync methods, the bottleneck is elsewhere and the MAC makes little difference.
2. For the tar over ssh method, the MAC makes a significant difference, with the new umac-64@openssh.com outperforming everything, and the default hmac-md5 coming a not-too-distant second.

Managing compressibility

The third tests aimed to find the best way to deal with compressibility. In addition to ssh's -C flag which enables compression within ssh, rsync offer the -z flag and tar offers both the -z and -j flags. The -j flag uses bzip2 for compression, while all the others use gzip.

All tests were performed using the arcfour cipher and umac-64@openssh.com MAC.

I conclude that:

1. On these computers where the connection speed is so fast as to not be limiting, not using compression beats using compression every time even when what is being transferred is compressible.
2. At least on these computers, tar over ssh (without compression) is significantly faster than every other method. Again, this may be because the two separate processes get around the limitations of the slow hard drive.
3. sshfs is terrible at transferring a large number of small files (as seen from the compressible case).
4. bzip2 is too slow to be used for on-the-fly compression.
5. The speed of rsync appears to be independent of whether and what type of compression is used.

Newer tests without hard drives

These newer tests were performed on a newer cluster, so are not directly comparable with the ones given above. The operating system this time was Ubuntu 12.04.3 LTS, running on two-core AMD Opteron 270 2.0GHz processors linked by a gigabit ethernet connection through an old but high performance Cisco switch. This time, RAM disks were used at either end to avoid the hard drive bottleneck; in the fastest tests, speeds of up to 0.9Gb/s were reached, showing that the network link is now the bottleneck.

The same data sets as before were used; one with lots of small compressible files, and one with 200 × 10MB incompressible files. All tests were using the Ciphers=arcfour128 and MACs=umac-64@openssh.com ssh options. This time, multiplexing connections was also tested. This was set up using ssh -M -S mux -fN <target>, and was used using the -S mux option passed to ssh. The results were:

I conclude that:

1. Multiplexing does not offer much of an advantage for any of these methods.
2. tar over ssh is still by far the fastest. rsync again comes second.
3. sshfs, sftp and to some extent scp are terrible at transferring a large number of small files. sshfs is also poor when transferring larger files too.
4. The results of this test are broadly in agreement with the previous results, now that the bandwidth limit imposed by the hard drive is removed. The only inconsistency is for tar over ssh for the compressible files, with the new result being more believable.