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

[Peter Jeremy]

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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
Url : http://mailman.barnet.com.au/pipermail/bugs/attachments/20071107/caaa310a/attachment.bin