[prev in list] [next in list] [prev in thread] [next in thread] 

List:       gentoo-user
Subject:    Re: [gentoo-user] Getting output of a program running in background after a crash
From:       Frank Steinmetzger <Warp_7 () gmx ! de>
Date:       2023-10-13 22:42:30
Message-ID: ZSnH1tHKvloacEmu () kern
[Download RAW message or body]


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" (application/pgp-signature)]

[prev in list] [next in list] [prev in thread] [next in thread] 

Configure | About | News | Add a list | Sponsored by KoreLogic