Re: hardware encryption,Re: hardware encryption
> https://openwrt.org/docs/techref/hardware/cryptographic.hardware.accelerators#finding_out_what_s_available_in_the_kernel
> is the only page I found wrt /proc/crypto and I do indeed have
> several 'skcipher' and 'shash' nodes with prio >= 300.
> That article also speaks about /dev/crypto, but I don't have that.
Yeah, kernel crypto is not well documented (in my opinion).
> So there's a reasonable chance I indeed do have HW accelerated crypto,
> but it doesn't seem to be near '10x' speed improvements.
Yeah, you won't see that kind of speedup across all agorithms.
On Aarch64, you will see the following speedups (give or take) over a
quality C implementation:
* AES - 6x
* SHA1 - 3.5x
* SHA2 - 9.5x
* PMULL - 12x
SHA3 is available on ARMv8.2. Apple M1's ship with it. I don't have
benchmark numbers for it (yet).
> Thermal issues may also play a role. I noticed that if I did a test
> after letting the device idle for a while, so it can cool off (?), did result
> in higher scores.
You should probably use an active cooling solution, like a fan.
Then, before your run benchmarks, move the CPU from standby mode to
performance mode. See, for example,
https://github.com/weidai11/cryptopp/blob/master/TestScripts/governor.sh.
Standby mode is a kind of slow start. When in standby mode the first
couple of algorithms you benchmark will be off. By about the third
algorithm, the cpu is no longer in standby mode.
By using performance mode you avoid the slow start that throws off
your benchmarks.
Jeff
Reply to: