Am Thu, Oct 12, 2023 at 08:35:21PM -0500 schrieb Dale: > Frank Steinmetzger wrote: > > Am Thu, Oct 12, 2023 at 10:44:39PM +0100 schrieb Michael: > > > >> Why don't you test throughput without encryption to confirm your > >> assumption? > > What does `cryptsetup benchmark` say? I used to use a Celeron G1840 in my > > NAS, which is Intel Haswell without AES_NI. It was able to do ~ 150 MB/s > > raw > > encryption throughput when transferring to or from a LUKS’ed image in a > > ramdisk, so almost 150 % of gigabit ethernet speed. > […] > I've never used that benchmark. Didn't know it exists. This is the > results. Keep in mind, fireball is my main rig. The FX-8350 thingy. > The NAS is currently the old 770T system. Sometimes it is a old Dell > Inspiron but not this time. ;-) > > root@fireball / # cryptsetup benchmark > […] > # Algorithm | Key | Encryption | Decryption > aes-cbc 128b 63.8 MiB/s 51.4 MiB/s > serpent-cbc 128b 90.9 MiB/s 307.6 MiB/s > twofish-cbc 128b 200.4 MiB/s 218.4 MiB/s > aes-cbc 256b 54.6 MiB/s 37.5 MiB/s > serpent-cbc 256b 90.4 MiB/s 302.6 MiB/s > twofish-cbc 256b 198.2 MiB/s 216.7 MiB/s > aes-xts 256b 68.0 MiB/s 45.0 MiB/s > serpent-xts 256b 231.9 MiB/s 227.6 MiB/s > twofish-xts 256b 191.8 MiB/s 163.1 MiB/s > aes-xts 512b 42.4 MiB/s 18.9 MiB/s > serpent-xts 512b 100.9 MiB/s 124.6 MiB/s > twofish-xts 512b 154.8 MiB/s 173.3 MiB/s > root@fireball / #
Phew, this looks veeeery slow. As you can clearly see, this is not enough to even saturate Gbit ethernet. Unfortunately, I don’t have any benchmark data left over from the mentioned celeron. (Perhaps that’s why the industry chose to implement AES in hardware, because it was the slowest of the bunch.) It looks like there is no hardware acceleration involved. But according to https://en.wikipedia.org/wiki/List_of_AMD_FX_processors#Piledriver-based and https://www.cpu-world.com/CPUs/Bulldozer/AMD-FX-Series%20FX-8350.html it has the extension. I’d say something is amiss in your kernel. Heck, even my ultra-low-end eeepc with its no-AES Atom processor N450 from 2009 is less than 50 % slower, and for aes-xts 512b it is actually faster! And that was a snail even in its day. It is so low-end that its in-order architecture is not vulnerable to spectre and meltdown. :D It just scrunched several minutes on updating the GPG keyring of its arch linux installation. eeePC # LC_ALL=C cryptsetup benchmark # Tests are approximate using memory only (no storage IO). PBKDF2-sha1 228348 iterations per second for 256-bit key PBKDF2-sha256 335222 iterations per second for 256-bit key PBKDF2-sha512 253034 iterations per second for 256-bit key PBKDF2-ripemd160 172690 iterations per second for 256-bit key PBKDF2-whirlpool 94705 iterations per second for 256-bit key argon2i 4 iterations, 71003 memory, 4 parallel threads (CPUs) for 256-bit key (requested 2000 ms time) argon2id 4 iterations, 71506 memory, 4 parallel threads (CPUs) for 256-bit key (requested 2000 ms time) # Algorithm | Key | Encryption | Decryption aes-cbc 128b 31.0 MiB/s 33.6 MiB/s serpent-cbc 128b 28.1 MiB/s 62.9 MiB/s twofish-cbc 128b 28.6 MiB/s 31.0 MiB/s aes-cbc 256b 24.0 MiB/s 25.6 MiB/s serpent-cbc 256b 28.3 MiB/s 62.7 MiB/s twofish-cbc 256b 28.6 MiB/s 31.0 MiB/s aes-xts 256b 32.5 MiB/s 33.4 MiB/s serpent-xts 256b 50.5 MiB/s 60.5 MiB/s twofish-xts 256b 25.6 MiB/s 30.7 MiB/s aes-xts 512b 25.0 MiB/s 25.6 MiB/s serpent-xts 512b 60.2 MiB/s 60.4 MiB/s twofish-xts 512b 30.2 MiB/s 30.7 MiB/s > root@nas:~# cryptsetup benchmark > […] > # Algorithm | Key | Encryption | Decryption > aes-cbc 128b 130.6 MiB/s 128.0 MiB/s > serpent-cbc 128b 64.7 MiB/s 161.8 MiB/s > twofish-cbc 128b 175.4 MiB/s 218.8 MiB/s > aes-cbc 256b 120.1 MiB/s 122.2 MiB/s > serpent-cbc 256b 84.5 MiB/s 210.8 MiB/s > twofish-cbc 256b 189.5 MiB/s 218.6 MiB/s > aes-xts 256b 167.0 MiB/s 162.1 MiB/s > serpent-xts 256b 173.9 MiB/s 204.5 MiB/s > twofish-xts 256b 204.4 MiB/s 213.2 MiB/s > aes-xts 512b 127.9 MiB/s 122.9 MiB/s > serpent-xts 512b 201.5 MiB/s 204.7 MiB/s > twofish-xts 512b 215.0 MiB/s 213.0 MiB/s > root@nas:~# Interesting; AES is much better than the FX-8350, but others are worse. There are many intricate factors, such as cache size, assembler optimisations and such. > > Ah right, you use NFS. If not, I’d have suggested not to use rsync over > > ssh, > > because that would indeed introduce a lot of encryption overhead. > > I thought nfs was the proper way. I use ssh and I use rsync, > separately. Didn't know they can be used together tho. When you do `rsync -ai source host:/path/to/destination/`, you use ssh for transport. > >>> I still think encryption is slowing it down some. As you say tho, > >>> ethernet isn't helping which is why I may look into other options later, > >>> faster ethernet or fiber if I can find something cheap enough. What do you mean with “ethernet is not helping”? As we could see above, your AES throughput cannot keep up with Gbit. > That may explain why I don't see as much load on my main rig then. It > has the extra instructions. I'm not sure if the 770T does or not. The mobo should have no influence on crypto performance. > It > has Ubuntu so I can't run the Gentoo CPU flag thingy. So, I checked > /proc/cpuinfo and it doesn't show it on the 770T but my main rig > Fireball does. So, it seems Fireball has it, older 770T NAS box does > not. That could be a bottleneck. Maybe. But interestingly, the NAS box shows higher AES throughput than fireball, probably through raw performance. (What processor does it have?) -- Grüße | Greetings | Salut | Qapla’ Please do not share anything from, with or about me on any social network. You call this cappucino? It’s not even sprinkled with Parmesan!
signature.asc
Description: PGP signature
