I found out that I can measure OpenSSL CPU processing time with the command:
#openssl speed -evp aes-256-cbc -elapsed
On an Intel 9th generation board, it consistently shows as 3 seconds:
Doing aes-256-cbc for 3s on 16 size blocks: 215093065 aes-256-cbc's in 3.00s
Doing aes-256-cbc for 3s on 16 size blocks: 215093065 aes-256-cbc's in 3.00s
Doing aes-256-cbc for 3s on 16 size blocks: 215093065 aes-256-cbc's in 3.00s
Doing aes-256-cbc for 3s on 16 size blocks: 215093065 aes-256-cbc's in 3.00s
Doing aes-256-cbc for 3s on 16 size blocks: 215093065 aes-256-cbc's in 3.00s
But on an Intel 10th generation board, it fluctuates and doesn't stay consistent
Doing aes-256-cbc for 3s on 16 size blocks: 215093065 aes-256-cbc's in 4.72s
Doing aes-256-cbc for 3s on 64 size blocks: 39247616 aes-256-cbc's in 3.19s
Doing aes-256-cbc for 3s on 256 size blocks: 9806239 aes-256-cbc's in 3.08s
Doing aes-256-cbc for 3s on 1024 size blocks: 2526470 aes-256-cbc's in 3.13s
Doing aes-256-cbc for 3s on 8192 size blocks: 307699 aes-256-cbc's in 3.05s
Even after referencing CPU-related parameters and adding configurations, the issue remains the same
Tuning the Oracle Solaris Kernel - Oracle Solaris Tunable Parameters Reference Manual
Changing power-related power options also yields the same result.
#poweradm set administrative-authority=none
Furthermore, even after trying to change BIOS options from the manufacturer, OpenSSL CPU processing time does not remain consistent.
This is an interesting one. I've been doing some checking this morning on my (admittedly very different) test system, which is an x86_64-based RHEL 7 container. And whilst I can be doing things in the background that certainly affect the actual throughput numbers dramatically, I always get every test completing in 2.99, 3.00 or 3.01 seconds. It's never gone significantly above or below three seconds elapsed once, no matter what I else I have the system doing. Which is pretty much what I'd expect.
Was this test running inside a Solaris zone, perhaps, and was that zone maybe hitting its CPU time limit, if one is configured, while you were running the test ? Or was it running under a user account that has a CPU usage or CPU time limit configured ? Other than things of this nature, I'm not sure what else I can think of that could cause such wide variability in the actual time taken versus the time the utility intended to take.
My guess is that the data above is incorrect or buggy.
It is unlikely the processing times you measured should be exactly the same each time, with hundredths of a second precision. Millisecond precision or better would be better for analysis.
The second scenario is more likely closer to being accurate because the processing times differ, which is the expected machine behavior.
It seems I copied and pasted incorrectly. I conducted the same incremental block test.
Doing aes-256-cbc for 3s on 16 size blocks: 135924296 aes-256-cbc's in 3.00s
Doing aes-256-cbc for 3s on 64 size blocks: 39009363 aes-256-cbc's in 3.00s
Doing aes-256-cbc for 3s on 256 size blocks: 10027211 aes-256-cbc's in 3.00s
Doing aes-256-cbc for 3s on 1024 size blocks: 2514644 aes-256-cbc's in 3.00s
Doing aes-256-cbc for 3s on 8192 size blocks: 312547 aes-256-cbc's in 3.00s
Maybe a smaller block size needs more iterations, and that takes longer.
On the other hand, a smaller block size might fit in the CPU cache.
Lots of HW-dependent details come into play...