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 [email protected] Automated List Manager [EMAIL PROTECTED]
