Am Thu, Oct 12, 2023 at 10:44:39PM +0100 schrieb Michael: > > >>>> It only does this when I'm copying files over. Right now I'm copying > > >>>> about 26TBs of data over ethernet and it is taking a while. Once I > > >>>> stop it or it finishes the copy, the CPU goes to about nothing, > > >>>> unless I'm doing something else. So it has something to do with the > > >>>> copy process. > > >>> > > >>> Or the network. What are you using to copy? If you use rsync, you can > > >>> make use the the --bwlimit option to reduce the speed and network > > >>> load. > > >> > > >> Reduce? I wouldn't complain if it went faster. I think it is about as > > >> fast as it is going to get tho. > > > > > > And that may be contributing to the CPU usage. Slowing down the flow may > > > make the comouter more usable, and you're never going to copy 26TB > > > quickly, especially over ethernet. > > > > > >> While I'm not sure what is keeping me from copying as fast as the drives > > >> themselves can go, I suspect it is the encryption. > > 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.
> > > If you're copying over the network, that will be the limiting factor.
> >
> > Someone posted some extra options to mount with and add to exports
> > file.
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 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.
>
> There are a lot of hypotheses in your statements, but not much testing to
> prove or disprove any of them.
>
> Why don't you try to isolate the cause by testing one system element at a
> time
> and see what results you get.
> […]
> Unless you're running Pentium 4 or some other old CPU, it is almost certain
> your CPU is capable of using AES-NI to offload to hardware some/all of the
> encryption/decryption load - as long as you have the crypto module built in
> your kernel.
The FX-8350 may be old, but it actually does have AES instructions.
Here is my Haswell i5 (only two years younger than the FX) with AES_NI:
~ LC_ALL=C cryptsetup benchmark
# Tests are approximate using memory only (no storage IO).
PBKDF2-sha1 1323959 iterations per second for 256-bit key
PBKDF2-sha256 1724631 iterations per second for 256-bit key
PBKDF2-sha512 1137284 iterations per second for 256-bit key
PBKDF2-ripemd160 706587 iterations per second for 256-bit key
PBKDF2-whirlpool 510007 iterations per second for 256-bit key
argon2i 7 iterations, 1048576 memory, 4 parallel threads (CPUs) for
256-bit key (requested 2000 ms time)
argon2id 7 iterations, 1048576 memory, 4 parallel threads (CPUs) for
256-bit key (requested 2000 ms time)
# Algorithm | Key | Encryption | Decryption
aes-cbc 128b 679.8 MiB/s 2787.0 MiB/s
serpent-cbc 128b 91.4 MiB/s 582.1 MiB/s
twofish-cbc 128b 194.9 MiB/s 368.3 MiB/s
aes-cbc 256b 502.3 MiB/s 2155.4 MiB/s
serpent-cbc 256b 90.3 MiB/s 582.5 MiB/s
twofish-cbc 256b 194.0 MiB/s 368.6 MiB/s
aes-xts 256b 2470.8 MiB/s 2478.7 MiB/s
serpent-xts 256b 537.4 MiB/s 526.1 MiB/s
twofish-xts 256b 347.3 MiB/s 347.3 MiB/s
aes-xts 512b 1932.6 MiB/s 1958.0 MiB/s
serpent-xts 512b 532.9 MiB/s 522.9 MiB/s
twofish-xts 512b 348.4 MiB/s 348.9 MiB/s
The 6 Watts processor in my Surface Go yields:
aes-xts 512b 1122,2 MiB/s 1123,7 MiB/s
--
Grüße | Greetings | Salut | Qapla’
Please do not share anything from, with or about me on any social network.
The severity of the itch is inversely proportional to the reach.
signature.asc
Description: PGP signature
