Hardware Acceleration isn't working properly

Started by bitmusician, August 04, 2020, 02:09:11 PM

Previous topic - Next topic
August 04, 2020, 02:09:11 PM Last Edit: August 04, 2020, 02:37:59 PM by bitmusician
Hi,

since updating from 20.1.9 to 20.7 the hardware acceleration isn't working properly. The time it takes to do the encryption has increased a lot (like if there's no hardware acceleration enabled). I've tested this on different hardware and tried it before updating, where it was working like expected.

Before updating the output of "openssl speed -evp aes-256-cbc" was:

Doing aes-256-cbc for 3s on 16 size blocks: 342721 aes-256-cbc's in 0.38s
Doing aes-256-cbc for 3s on 64 size blocks: 600792 aes-256-cbc's in 0.38s
Doing aes-256-cbc for 3s on 256 size blocks: 315407 aes-256-cbc's in 0.41s
Doing aes-256-cbc for 3s on 1024 size blocks: 257082 aes-256-cbc's in 0.27s
Doing aes-256-cbc for 3s on 8192 size blocks: 104498 aes-256-cbc's in 0.08s
OpenSSL 1.0.2o-freebsd  27 Mar 2018
built on: date not available
options:bn(64,64) rc4(16x,int) des(idx,cisc,16,int) aes(partial) idea(int) blowfish(idx)
compiler: clang
The 'numbers' are in 1000s of bytes per second processed.
type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes
aes-256-cbc      14324.34k   100442.61k   198754.93k   991066.23k 10957409.48k



After updating it's:

Doing aes-256-cbc for 3s on 16 size blocks: 55925433 aes-256-cbc's in 3.06s
Doing aes-256-cbc for 3s on 64 size blocks: 22414986 aes-256-cbc's in 3.02s
Doing aes-256-cbc for 3s on 256 size blocks: 5712456 aes-256-cbc's in 3.05s
Doing aes-256-cbc for 3s on 1024 size blocks: 1069014 aes-256-cbc's in 3.01s
Doing aes-256-cbc for 3s on 8192 size blocks: 183532 aes-256-cbc's in 3.05s
Doing aes-256-cbc for 3s on 16384 size blocks: 62895 aes-256-cbc's in 3.00s
OpenSSL 1.1.1d-freebsd  10 Sep 2019
built on: reproducible build, date unspecified
options:bn(64,64) rc4(16x,int) des(int) aes(partial) idea(int) blowfish(ptr)
compiler: clang
The 'numbers' are in 1000s of bytes per second processed.
type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes  16384 bytes
aes-256-cbc     292181.85k   475708.72k   479963.48k   363942.35k   492192.46k   343490.56k



greetz,
bitmusician

Sorry, as usual wrong binary...

/usr/local/bin/openssl

You can find this topic many times in the forum archives.


Cheers,
Franco

August 04, 2020, 02:53:31 PM #2 Last Edit: August 04, 2020, 02:57:18 PM by franco
PS: it doesn't look slower actually... and 3 seconds test only took less than one second... can't trust these results

August 04, 2020, 03:12:10 PM #3 Last Edit: August 04, 2020, 03:14:55 PM by bitmusician
Thanks for your reply!

Using "/usr/local/bin/openssl speed -evp aes-256-cbc" doesn't make any difference.

Doing aes-256-cbc for 3s on 16 size blocks: 51683849 aes-256-cbc's in 3.09s
Doing aes-256-cbc for 3s on 64 size blocks: 21974176 aes-256-cbc's in 3.06s
Doing aes-256-cbc for 3s on 256 size blocks: 5865967 aes-256-cbc's in 3.06s
Doing aes-256-cbc for 3s on 1024 size blocks: 1462847 aes-256-cbc's in 3.02s
Doing aes-256-cbc for 3s on 8192 size blocks: 185138 aes-256-cbc's in 3.04s
Doing aes-256-cbc for 3s on 16384 size blocks: 91663 aes-256-cbc's in 3.01s
OpenSSL 1.1.1g  21 Apr 2020
built on: Mon Jul 27 22:42:08 2020 UTC
options:bn(64,64) rc4(16x,int) des(int) aes(partial) blowfish(ptr)
compiler: cc -fPIC -pthread -Wa,--noexecstack -Qunused-arguments -O2 -pipe  -DHARDENEDBSD -fPIE -fPIC -fstack-protector-all -fno-strict-aliasing -DL_ENDIAN -DOPENSSL_PIC -DOPENSSL_CPUID_OBJ -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DKECCAK1600_ASM -DRC4_ASM -DMD5_ASM -DAESNI_ASM -DVPAES_ASM -DGHASH_ASM -DECP_NISTZ256_ASM -DX25519_ASM -DPOLY1305_ASM -D_THREAD_SAFE -D_REENTRANT -DNDEBUG
The 'numbers' are in 1000s of bytes per second processed.
type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes  16384 bytes
aes-256-cbc     267970.94k   459215.43k   490346.96k   496731.30k   499052.09k   499301.93k


I test the hardware acceleration every time there's an update and the last time that "bad" values like these appeared was (I think) in version 19.1.8. So well I thought I could trust that command line output. Do you have a more trustful method of testing that mechanism?