Leaving out security concerns, which is the most bandwidth-efficient use of rsync for long-distance WAN transfers: rsh/ssh or modules?

I understand that modules assume no encryption by default, but everything I've read suggests that the CPU overhead for rsh/ssh is negligible on modern systems (e.g. multi Xenons), and the pipe won't back up with <1Gbs network speeds. I know that there is additional overhead with the rsh having to originate the remote shell and execute rsync, but given the amount of data, this seems negligible.

It would be a heck of a lot easier to just open up rsh and use rsync this way for this implementation, rather than set up a module for every server, but if the difference is measurable, I will of course do it with modules. Anyone have experience/opinions?


The rsync protocol, be it implemented straight by TCP or using SSH, is (maybe arguably) the most bandwidth efficient synchronization algorithm. When you use it by SSH in order to get authentication and encryption, there is a small overhead.

  • 1
    If you have lots of bandwidth available the encryption process becomes substantial and might even slow down your connection. If you want to find a middle ground between plain-text and encrypted, try using ssh with the arcfour cipher (ssh -c arcfour). It's not as secure as AES or 3DES, but is much faster. – mtak Apr 17 '14 at 12:59
  • 1
    As a side note, AES can also be quite fast on newer CPUs due to the aes-ni instruction set. I haven't done any testing on how it influences ssh connections transfer speeds but for example, in the case of hard drive encryption, aes-ni has more than 3 times the speed of normal aes. – Florin Asăvoaie Apr 17 '14 at 14:42
  • Thanks folks. Sorry I wasn't clear. Leave SSH and encryption out of it; which would be more bandwidth efficient: straight rsync over rsh, or rsync using a daemon/module setup? (Or is it negligible?) Thanks. – kiwisan Apr 18 '14 at 16:19
  • Negligible I'd say. – Florin Asăvoaie Apr 18 '14 at 17:28

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.