OS: Linux (SuSE 9.1)
Version: 0.9.7d
1 or 2 Xeon CPUs (with hyper threading)

I've found out with the speed test, that executing on a hyper threading
system is disastrous for performance. These examples show 3DES, because
the gap is largest. The same problem applies to AES, though:

a) 1 CPU, HT disabled (kernel param: maxcpu=1):

openssl speed -evp des-ede3-cbc -multi 1
[...]
10667.54k, 15557.64k, 17765.49k, 18432.45k, 18621.22k

Throughput values are stable for 2 and 4 processes (not shown here).


b) 2 CPU, HT disabled (kernel param: maxcpu=2):

openssl speed -evp des-ede3-cbc -multi 1
[...]
10717.38k, 15675.78k, 17909.25k, 18689.79k, 18922.20k

openssl speed -evp des-ede3-cbc -multi 2
[...]
21348.31k, 31154.92k, 35656.59k, 37092.47k, 37543.44k

Throughput approximately doubled for 2 parallel processes, remaining stable for 4 processes


c) 2 CPU, HT enabled (kernel param: maxcpu=4):

openssl speed -evp des-ede3-cbc -multi 1
[...]
10572.02k, 15590.19k, 17916.49k, 18631.27k, 18849.50k

openssl speed -evp des-ede3-cbc -multi 2
[...]
21190.51k, 31067.75k, 35789.25k, 37247.01k, 37689.73k

openssl speed -evp des-ede3-cbc -multi 4
[...]
5025.19k, 4677.94k, 4553.19k, 4451.48k, 4422.67k

1 and 2 processes behave almost like in the other two cases, but the
throughput for four processes is between 50% and 70% worse than in the 1
process case. Again: 1 CPU w/o hyper threading is way faster than 2 CPUs
with HT!?

I expect this to be a bug in OpenSSL. However, I'm not an expert in
hyper threading, maybe this behavior is expected for homogeneous
workload like encrypting?

Sincerely,
Jan Schmidt

__________________________________________________ ____________________
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager majordomo@openssl.org