Perhaps the bottleneck isn’t always bandwidth – but does changing ssh cipher make any difference?
Using a derivative of :
rsync -W --delete --no-owner --no-group --no-perms \
-e ssh \
-arv /source/ remote@destination:/destination/path/In unscientific tests, it looks like ssh parameters might do something when copying a 4GiB file between two random virtual machines in different data centres, but both in London.
| SSH Variant | Speed |
| -e “ssh” | ~45MB/s |
| -e “ssh -x -T” | ~44MB/s |
| -e “ssh -x -T -c chacha20-poly1305@openssh.com” | ~42MB/s |
| -e “ssh -x -T -c aes128-ctr” | ~47MB/s |
| -e “ssh -x -T -c aes256-gcm@openssh.com” | ~50MB/s |
| -e “ssh -x -T -c aes128-gcm@openssh.com “ | ~45MB/s |
I’m not sure if these results are particularly insightful / useful.
You can rebuild ssh and sshd with a null cypher for benchmark purposes if you’re interested. Turning compression on and off can also make a big difference depending on the CPU availability on both ends. There are also multi-threaded versions of both client and server that can help.
Thanks – I was sure I’d written something before about speed(s) but couldn’t immediately find it 🙂 this was a poor mans attempt at stopping myself from doing pointless premature optimisations in the future !