[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: difference between jari's and hvr's package
On Wed, 6 Mar 2002, Steve Weigand wrote:
> On Wed, Mar 06, 2002 at 11:14:59PM +0200, Jari Ruusu wrote:
> > Tested on 2.4.18 kernel, Pentium-2 300 MHz, ST34342A IDE disk
> > Implementation Cipher Total CPU cycles spent in system mode
> > -------------- ------ -------------------------------------
> > cryptoapi AES-128 54 %
> > loop-AES AES-128 36 %
> > cryptoapi serpent-128 81 %
> > loop-AES serpent-128 78 %
> >
> > All above implementations used the disk at maximum data transfer rate
> > supported by the disk, so megabytes/sec rate was same for all ciphers on
> > unloaded test box.
> >
> > Serpent implementations used same cipher source code. Cryptoapi overhead on
^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> > loop encryption seems to be few percent of CPU cycles.
i.e. only the serpent test used the same cipher implementation;
I assume he used the asm optimized aes optimization for the AES test,
which would be a bit unfair -- especially since he didn't tell us
explicitly...
> That's strange. So AES does much more in user-mode than serpent does?
> So that's why serpent's run time is dominated by system-mode cpu
> cycles whereas AES is not? Why is that?
> What part is running in user-mode out of curiosity?
none...
> And why is there such a large discrepancy between cryptoapi's AES
> CPU time and loop-AES's AES CPU time? Context switching?
...assembler versus C version... :-)
well, so we can say, that loop-AES is definitely a bit faster...
...somewhere around 3% :-) btw, we also don't know whether which loop
patches were used... maybe jari's preallocated buffer logic influences a
bit as well..
regards,
--
Herbert Valerio Riedel / Phone: (EUROPE) +43-1-58801-18840
Email: hvr@hvrlab.org / Finger hvr@gnu.org for GnuPG Public Key
GnuPG Key Fingerprint: 7BB9 2D6C D485 CE64 4748 5F65 4981 E064 883F 4142
-
Linux-crypto: cryptography in and on the Linux system
Archive: http://mail.nl.linux.org/linux-crypto/