[BUGS] OpenSSL speedup on those low end Via C3 chips

[Edward Irvine]

Good suggestion.

Running the following command consistently gives an encryption speed  
of 22.8 Mbytes/sec.

dd \
    if=/dev/zero \
    bs=1024k \
    count=1000 |\
openssl enc \
    -e \
    -aes-128-cbc \
    -engine cryptodev \
    -pass file:password \
    -out /dev/null

That's still pretty fast, and more than adequate many real-world WAN  
IPSec tasks. But it is nothing remotely like the figures in my first  
post. This suggests that there is something buggy with the openssl  
speed command.

By comparison, a 64 bit version of openssl, compiled with Sun's C  
compiler and running on one of Sun's new x2200 Opteron machines can  
do about four times that speed, i.e. 88 Mbyte/sec.

Eddie

On 07/11/2007, at 11:09 PM, Peter Jeremy wrote:

> On Wed, Nov 07, 2007 at 10:36:49PM +1100, Edward Irvine wrote:
>> The 'numbers' are in 1000s of bytes per second processed.
>> type             16 bytes     64 bytes    256 bytes   1024 bytes    
>> 8192
>> bytes
>> aes-128-cbc      14837.51k    70870.03k   199466.36k  5435667.18k
>> 6065857.95k
>>
>> ^^^^^^^^^^^
>>
>> Is that 6 Giga-bytes/sec? i.e. 60 Giga-bits/sec of 128 bit AES  
>> encryption?
>> Am I reading this right?
>
> That's what the number says but I'm also a bit dubious.  That's more
> than 8 bytes per clock-cycle - which implies that they have a 128-bit
> wide, fully unrolled AEC-128-CBC in hardware.  That strikes me as a
> lot of silicon to dedicate - especially since you can't actually use
> that bandwidth because you couldn't get the data on or off the chip at
> that rate.
>
> I'd be inclined to do some 'trust but verify' checking:  Feed some
> AES-128 test vectors in and check you get the right answers, then
> encrypt some random data in similar-sized small chunks and cross-check
> it against the same data encrypted in larger chunks and bootstrap
> yourself up to the 8K blocks that seem too good to be true.  I've
> seen one benchmark where the default set of switches meant that you
> wound up bypassing the I/O calls completely - which lead to reports
> of amazingly good performance.
>
> The other thing would be to cross check the openssl times against
> a stopwatch in case the system clock is going funny.
>
> -- 
> Peter Jeremy
> Please excuse any delays as the result of my ISP's inability to  
> implement
> an RFC2821-compliant MTA.
> _______________________________________________
> BUGS mailing list
> BUGS at bugs.au.freebsd.org
> http://mailman.barnet.com.au/mailman/listinfo/bugs

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.barnet.com.au/pipermail/bugs/attachments/20071108/45f24230/attachment-0001.html