speed-up rsync and scp xfers on a LAN - choice of cipher is key!

graysky · 2012-02-28 23:20:19

I found an older thread (circa 2005) on this topic and wanted to post the results of my analysis on "modern" hardware.

Summary
After measuring how long various v2 ciphers took to transfer a 500 MB on a Gigalan network, either arcfour, arcfour128, or arcfour256 gave the fastest result on modern hardware.

Experiment
Using scp, a 500 MB file from computer A to computer B was transferred (5 times totally) over my LAN and the results were timed. A different 500 MB file for each test was generated from /dev/urandom for each of the trials to avoid any disk caching trickery. It is noteworthy to mention that most of the ciphers were CPU bound; in other words, watching htop throughout the experiment, most of the ciphers cause one core to hit 100 % usage. These have been denoted in the data with a pink color. A blue color shows those ciphers that did not max out any single core.

Hardware details
Both computer A and computer B are Intel P45-based boards. Computer A is an Intel X3360 @ 3.40 GHz and computer B is an Intel E5200 @ 3.33 GHz. Both machines had their CPU governors set to 'performance' for this test. Both machines have Gigalan NICs (onboard) using 4k jumbo frames. The LAN itself iuses a gigalan switch (Cisco SR2016T-NA) and is comprised entirely of CAT5E cables (wired the house myself). Hardrive access time are irrelevant in this test since transfers are to/from tmpfs (/scratch is mounted to tmpfs).

Results

Larger throughputs are desired.

Smaller times are desired.

The variation between the 5 runs is pretty tight on the whole; the standard errors are plotted on the bar graphs. There is no statistically significance difference between the arcfour, arcfour128, and arcfour256 ciphers in this test as seen by an ANOVA analysis on the five runs/cipher:

Methods and Data
The script is here: https://github.com/graysky2/bin/blob/ma … hertest.sh
The raw data are here: http://pastebin.com/uqHaM72q

Note about security: The experiments outlined above are looking at a throughput endpoint. No consideration to security was implicate in their design. Use your brain: if operating on an unsecured network, high quality ciphers are your friend. If operating on a secured network, perhaps speed is your goal. You have been warned.

Last edited by graysky (2016-07-20 22:02:37)

graysky · 2012-05-13 19:18:47

I should add that users need not specify the cipher in the scp or rsync command, simple do it on a per-hosts basis in ~/.ssh/config on the machine that will SEND the files:

Host  mars
Ciphers arcfour128

Xyne · 2012-05-13 20:44:55

If you're on a secure network then you should be able to bypass SSH altogether. If not, then the strength of the cipher is more important than the speed of the transfer. Afaik, the RC4 ciphers are considered weak and not recommended. I think you should include a caveat about security to warn other users before they naively follow your suggestions.

graysky · 2012-05-16 20:36:06

@Xyne - Valid point. My assumption was for secure network. I will edit the main post. I googled for completely disabling the encryption but didn't find anything that works. Are you aware of the proper syntax?

Arch Linux

#1 2012-02-28 23:20:19

speed-up rsync and scp xfers on a LAN - choice of cipher is key!

#2 2012-05-13 19:18:47

Re: speed-up rsync and scp xfers on a LAN - choice of cipher is key!

#3 2012-05-13 20:44:55

Re: speed-up rsync and scp xfers on a LAN - choice of cipher is key!

#4 2012-05-16 20:36:06

Re: speed-up rsync and scp xfers on a LAN - choice of cipher is key!

Board footer