* Aleix Conchillo Flaque ([EMAIL PROTECTED]) wrote:
> hi again,
>
> as i said yesterday i'm doing some tests with cryptographic hardware (in
> my case nCipher's).
>
> now that i have loaded the engine, i'm getting real strange results. the
> same test with hardware enabled is much slower than the software version.
>
> it is really weird, because the "openssl speed -engine chil" command
> seems to be as fast as desired.
>
> do i have to set something else? is there any documentation on the net?
> am i getting more dummy everyday?
I've written oodles about this sort of thing in the past - so perhaps a
trawl of the archives might turn up enough "documentation" to keep you
happy. Of if not happy, at least busy. :-)
The short answer(s) are probably as follows, but not having seen your
numbers I'm working blind and so you should take this with a pinch of
salt.
When using hardware, you probably want to use the "-elapsed" flag to
"openssl speed". The reason is that by default it will measure CPU usage
of the openssl speed command so that the benchmarks are more accurate
and resistant to external tasks that might be happening on the host
system. However, if the crypto is taking place in hardware, the library
representing the hardware is probably spending the majority of time in
blocking calls (ioctl() if it talks directly to kernel drivers, though I
think ncipher/chil uses select/poll to talk to a privileged daemon
process instead?). Anyway, this will seriously mess up the numbers and
give wildly overstated estimates. If the program spends most of the time
sleeping waiting for responses from hardware, it'll appear that the
program used very little CPU time to achieve the crypto operations and
so will deduce that if it could have all the CPU time to itself it would
be very very fast indeed! Which is nonsense of course. "-elapsed" will
simply measure the running time, rather than CPU usage, which (provided
you try to keep the system from doing other tasks at the same time)
should prove more accurate.
If the above is true, that should merely make "openssl speed" say your
hardware is as slow as you thought it was from your own test program. As
for the reason why that might be the case, here are some possibilities;
(1) your crypto hardware could actually be slow,
(2) your host system could actually be quite fast in software,
(3) your crypto hardware could be highly parallel and your application
could be linear (as is certainly the case with "openssl speed").
W.r.t. (3), it may happen that the crypto hardware has a number of
internal cryptographic units that it can distribute workload too, such
that if you keep providing it with enough crypto operations to do *AT
THE SAME TIME*, then the total throughput of operations could be what
you were expecting. What this means however is that each individual unit
on its own would be perhaps slower than you were expecting.
Or put another way, if you have a device claiming to do 1000 RSA
operations a second that is internally built out of 10 parallel
processing units, then each processing unit itself is probably capable
of doing 100 RSA operations a second, ie. 10 milliseconds each. If you
only ever give the whole device one operation to do at a time, only one
processing unit will be in use at a time, and so your total performance
will be that of one unit and not that of all ten.
"openssl speed" only does one crypto operation at a time unless you use
the "-multi <n>" switch (and it is supported on your version of openssl
and host system). Looking briefly at your sample source code, that has
the same problem. This is probably what is limiting the performance you
are seeing - try executing a few copies of your program at the same time
and see what the total performance between them looks like.
Regards,
Geoff
--
Geoff Thorpe
[EMAIL PROTECTED]
http://www.openssl.org/
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
