Since getting Debian up and running on my D-Link DNS-323 NAS, I’ve blogged about the slowness of secure copy to the device. This is due to the CPU maxing out when de-crypting. Peter Lieverdink suggested I might get better performance using a different algorithm such as blowfish.
I thought I’d give it a shot and see. The default order for encryption for SSH2 is aes128-cbc, 3des-cbc, blowfish-cbc, cast128-cbc, arcfour128, arcfour256, arcfour, aes192-cbc, aes256-cbc, aes128-ctr, aes192-ctr, aes256-ctr. I set up a transfer of a 100MB uncompressed tarball using each of these protocols to see which one provided the best performance. For comparison purposes, I copied the same 100MB file over CIFS, NFS and plain FTP (but keep in mind that with scp there are a few seconds of key negotiation which the others don’t have). Here are the results.
|
Protocol |
Encryption |
Time (real) |
Time (user) |
Time (sys) |
Speed |
|---|---|---|---|---|---|
|
CIFS |
N/A |
0m9.943s |
0m0.004s |
0m0.328s |
10.36MB/s |
|
FTP |
N/A |
0m14.075s |
0m0.008s |
0m0.100s |
7.32MB/s |
|
NFS |
N/A |
0m16.656s |
0m0.000s |
0m0.164s |
6.18MB/s |
|
SSH2 |
aes128-cbc |
0m39.997s |
0m1.464s |
0m0.188s |
2.58MB/s |
|
SSH2 |
3des-cbc |
2m21.635s |
0m8.921s |
0m0.224s |
0.73MB/s |
|
SSH2 |
blowfish-cbc |
0m28.208s |
0m1.956s |
0m0.164s |
3.65MB/s |
|
SSH2 |
cast128-cbc |
0m40.928s |
0m2.376s |
0m0.224s |
2.52MB/s |
|
SSH2 |
arcfour128 |
0m21.958s |
0m0.876s |
0m0.212s |
4.69MB/s |
|
SSH2 |
arcfour256 |
0m23.014s |
0m0.784s |
0m0.252s |
4.46MB/s |
|
SSH2 |
arcfour |
0m21.846s |
0m0.860s |
0m0.192s |
4.72MB/s |
|
SSH2 |
aes192-cbc |
0m44.934s |
0m1.632s |
0m0.176s |
2.29MB/s |
|
SSH2 |
aes256-cbc |
1m6.052s |
0m1.884s |
0m0.176s |
1.56MB/s |
|
SSH2 |
aes128-ctr |
0m42.252s |
0m1.568s |
0m0.160s |
2.44MB/s |
|
SSH2 |
aes192-ctr |
0m46.452s |
0m1.740s |
0m0.196s |
2.22MB/s |
|
SSH2 |
aes256-ctr |
0m50.765s |
0m1.808s |
0m0.220s |
2.03MB/s |
Looks like the fastest encryption to use is one of the arcfour variants (which you can set in your ~/.ssh/config). Let me know if you see any issues with my numbers!
-c
5 thoughts on “Speed test on the DNS-323”
Hi Chris,
Thanks for posting this test. I was wondering why scp with ssh was so slow on my DNS-323 compared to nfs / cifs, and it’s nice to see some hard numbers for the different encryption algorithms.
Cheers,
Nathan
No worries. Apparently there is a crypto chip which might have a working Linux driver soon. That means speed should increase.
-c
Thanks for sharing this on your blog! Found it on google right away when I was boggled that SCP was going at 2MB/s while Finder was going four or five times faster to the same DNS-323 device. I made a .ssh/config on my laptop with:
Ciphers arcfour128,arcfour256,aes128-ctr,aes256-ctr,aes128-cbc
And now transfers are going 5.1MB/s – 5.5MB/s. Quite a jump in speed, although I’d be even happier with it saturating my gigabit ethernet 🙂
I was a little worried that restricting my cipher list to prefer the (presumably) less secure arcfour128 might leave me vulnerable on more important SSH connections going out to the big bad internet. Restricting ciphers server-side would also mean not having to setup cipher changes on every computer that connects to my dns-323.
After a little poking, the same Ciphers command from ssh_config also works in sshd_config. The client picks from the available ciphers, so I had to restrict the server ciphers to only thw arcfour128 cipher as follows:
Ciphers arcfour128
One sshd restart later and my wife’s comp is going at 5MB/s too, without any config changes on her comp. Thanks again Chris for sharing your test results.
Great, thanks for that Eric! 🙂 I think the later kernel has support for the hardware encoding chip, that might improve things.
-c