Here’s what I got with my i5 8250U with a (probably cheap, mediocre) ssd and 8GB ddr4 ram:
What OS are you running?
Kubuntu 20.04 with Linux kernel version 5.6.14
This is what I get with Intel Core i7-3930K, on Asus P9X79-E WS, with 64 GB of DDR3-1600, running CentOS 7.7.1908 running Linux 3.10.0-1062.el7.x86_64 kernel, running openssl 1.0.2k-fips.
Time to update your kernel?
Not sure if it is the kernel, openssl, the RAM, the motherboard, and/or the CPU.
This is part of what makes running this test so difficult in order to come up with some kind of a meaningful answer/conclusion.
The more variables there are, the complexity and the number of permutations of the test that will need to be run out.
One of the biggest reasons why I haven’t updated a lot of stuff on the system is because I also don’t want to break other stuff that’s already working (e.g. NFSoRDMA).
Support for that is rather “fragile”.
There are no kernel updates for rhel based distributions only patches. While could update to 7.8 this still would not pull a newer kernel. He would have to update to CentOS 8 which runs the 4.18 kernel.
Yeah…which, I’m not sure if that would cause other problems for me. (Hardware compatibility issues with NFSoRDMA or software compatibility issues for the CAE programs that I use that hasn’t been certified to run on CentOS 8 yet.)
It’s one of those “you fix one problem, but break or create many other problems.”
It’s not a unique problem to Linux but yeah I feel your pain.
For a true apples to apples comparison it needs to stay with your exact hardware setup.
@alpha754293 why don’t you just get a live USB of some newer version of fedora running the 5.x kernel, and then run the test?
My bad, i’m relatively new to linux
No you’re fine. It’s one of those things you pick up.
Rhel freezes their kernel and backports patches.
Each major release is supported for 10 years which is why it’s used so much in the enterprise.
Could it be that comparing my result to OP’s is “flawed”? My OpenSSL version is newer.
Your hardware, and software versions are different than his.
It would be interesting if you spun up a CentOS 7.8 live USB and ran the test again to see your performance delta.
I downloaded the centos-kde iso from here but on installation it asked me to install a kernel and I don’t know how to do that (lol noob)
lots of googling later i maybe found something but currently booted to windows not linux =/
I don’t know, that’s why I gave the disclaimer. It is a pretty solid way to judge maximum single core performance between CPUs in general. And when averaging out a couple runs back to back it is also very consistent. But I have no experience with benchmarking hashing algorithms and most of my systems are packed up for moving currently. So I can’t even run stuff myself right now.
In case its relevant, here’s what my 2700x puts out
OpenSSL 1.1.1d FIPS 10 Sep 2019 built on: Thu Oct 3 00:00:00 2019 UTC options:bn(64,64) md2(char) rc4(8x,int) des(int) aes(partial) idea(int) blowfish(ptr) compiler: gcc -fPIC -pthread -m64 -Wa,--noexecstack -Wall -O3 -O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -fexceptions -fstack-protector-strong -grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection -Wa,--noexecstack -Wa,--generate-missing-build-notes=yes -specs=/usr/lib/rpm/redhat/redhat-hardened-ld -DOPENSSL_USE_NODELETE -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 -DZLIB -DNDEBUG -DPURIFY -DDEVRANDOM="\"/dev/urandom\"" -DSYSTEM_CIPHERS_FILE="/etc/crypto-policies/back-ends/openssl.config" The 'numbers' are in 1000s of bytes per second processed. type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes 16384 bytes sha256 248651.25k 634125.85k 1311330.13k 1773534.55k 1985853.13k 1996559.70k
IIRC, Zen is really good at hashing…
Yes and no, I do seem to recall zen is particularly good at openssl related tasks, maybe its the huge cache vs. intel, maybe its just instruction set optimisation. Either way, it was one of the benchmarks AMD cherry picked to illustrate zen performance back in the day IIRC.
In any case, if you’re wanting fast hashing performance maybe checking performance on a Zen2 part might be worth it. For single thread, even something like a 3300x. Apparently they clock like a champ.
For what it’s worth, here’s Icelake in a MacBook Air. i7 quad core at 1.2ghz - 3.8ghz boost.
[email protected] ~ % openssl speed sha256 Doing sha256 for 3s on 16 size blocks: 12829129 sha256's in 2.98s Doing sha256 for 3s on 64 size blocks: 7069845 sha256's in 2.98s Doing sha256 for 3s on 256 size blocks: 2993711 sha256's in 2.98s Doing sha256 for 3s on 1024 size blocks: 920891 sha256's in 2.99s Doing sha256 for 3s on 8192 size blocks: 121577 sha256's in 2.98s LibreSSL 2.8.3 built on: date not available options:bn(64,64) rc4(16x,int) des(idx,cisc,16,int) aes(partial) blowfish(idx) compiler: information not available The 'numbers' are in 1000s of bytes per second processed. type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes sha256 68852.37k 151846.20k 257157.92k 315589.15k 333756.95k [email protected] ~ %
hashcat is one such implementation, but not sure how useful it’d be to you.
Are you sure you need sha256? Also, why limit yourself to single core?
(I’m thinking it might be faster to encrypt/decrypt using aes-gcm or some such thing, not sure, but it might be)