Re: openssl speed benchmarks (was Re: [Openvpn-users] a couple of questions)

[Jon B. <jon...@la...>]

Den 16. jun 2004, kl. 18:07, skrev David Haworth , David Haworth:

>> a intel 3.06 GHz though not completely idle got:
>> aes-128 cbc      30871.89k    31260.69k    31642.28k    31615.66k     
>> 31645.70k
>>
>> my powerbook 1.33Ghz got
>> aes-128 cbc      38118.21k    41516.88k    41268.42k    40523.62k     
>> 41802.05k
>
> now that's interesting. the 1.3G g4 powerbook got a significantly  
> higher score than a 3G p4. I wonder why. bus speed is lower, altivec  
> perhaps? would openssl support that?

i think it is altivec, but i am not sure, because that 3G P4 is our  
server, and other users probably used it while i was running the test.  
But a rerun just now here after work gives the same score, so i think  
it is the altivec that adds
performance to the G4.


>> This is interesting if you compare it to your G5, which is a dual and  
>> pr. cpu is about 35%
>> faster than my single G4. However if you look at your results, they  
>> are just about 2.5
>> times faster. If you take the cpu speed factor, and the 2 cpus, that  
>> gives 1.35*2 = 2,7
>
> well, 2.5 vs 2.7 seems fair enough, you rarely get twice the speed out  
> of a duallie. that difference in performance would seem to imply to me  
> that openssl scales very well over cpu's but that there is a little  
> overhead from whatever source (osx perhaps) to balance things over  
> both cpu's properly. certainly it would be interesting trying it on a  
> quad and 8 way box too, not that I have one to hand :)
>
> I don't think that any of the improvements in the g5 proc are likely  
> to make too much of a difference to openssl speeds though. there is no  
> need for >32bit addressing and crypto is perhaps not the best type of  
> program for long pipelines where branch prediction might cause a  
> bigger problem (I'm clutching at straws here, not sure) so I really  
> don't know.
>
> my g5 running only 1 thread gets this result
>
> aes-128-cbc      53196.23k    56806.46k    62308.81k    60952.53k     
> 62393.86k

what clockspeed does that have ?


> which is slightly more than half the dual thread attempt, so that  
> seems to be saying good things about openssl's threading.

well, i suppose each packet can be handled in parallel?


> what I find very interesting is that using the athlon single proc.  
> using multiple threads makes performance slightly worse...  
> understandable. using more than 2 threads on the duallie gets very  
> little advance. again, I understand this. but using multiple threads  
> on the little via chip reaps big rewards, esp with the bigger block  
> sizes, although it murders the machine with massive load averages and  
> very laggy response.
>
> this is at 10 threads:
> (null)           24912.90k   107973.05k   303573.21k   606096.96k   
> 1196668.44k
>
> 100 threads:
> (null)           37495.22k   161566.05k   439774.14k   783542.34k   
> 1864134.09k
>
> ie I'd say that ethernet and pci bus traffic are the bottleneck to one  
> of these cpu's

speaking of PCI busses... i need 4 netcards, and i would prefer the  
possibility of 5 or more.
What mainboard do you use ?


> without the evp flag it gets a score similar to your fw:
>
> aes-128 cbc       5709.79k     5792.67k     5814.92k     5797.15k      
> 5831.65k

yeah, but what about blowfish, blowfish on my hardware runs almost  
twice as fast as AES.


> incidentally, the aes acceleration can cope with higher rates than  
> just 128bit
>
> aes-256-cbc      25523.18k    95334.00k   259990.24k   453591.16k    
> 581554.67k
>
> the board I'm using is one of these:
>
> http://www.viavpsd.com/product/epia_MII_spec.jsp?motherboardId=202

dammit, just one pci slot.


> http://linitx.com/product_info.php? 
> products_id=414&osCsid=918d32a8a21e5e1c7a3696d8907913a8
>
> apparently via are going to be adding sha1 and sha256 offload to their  
> next processor, and some rsa help too. now if only they'd add blowfish  
> for us geeks, and des&md5 cos damn, it would make a fantastic  
> /etc/passwd cracking engine :)
>
> is that helpful?

muchos gratios :)




JonB