Hi Tom,
Yea the elapsed time is what you want to be looking at. The reason the CPU time is giving ridiculously high results is because it's telling you how long the exp took on the machines' CPU which, if you're offloading it to a piece of h/w, is going to be very low. The elapsed time tells you how many exps in actual time.
As Ben said, the performance given by the openssl speed utility, depends on how your hardware works. Does your h/w require parallel access to the h/w device (multi-thread / process) to achieve it's performance? If so, it will under perform with "speed" because it is a single threaded program. It submits one exp and waits for the result before submitting the next one. Multithreaded/process applications like Apache will be able to make use of such hardware because they can submit many exps in parallel to a device. If your hardware is designed to provide extremely low latency for sequential mod exps then speed should be perfect for your benchmarking.
Do you have proprietry applications to test the performance of your card? How do they perform?
Diarmuid.
-----Original Message-----
From: Tom Biggs [SMTP:[EMAIL PROTECTED]]
Sent: Tuesday, October 02, 2001 7:40 PM
To: [EMAIL PROTECTED]
Subject: Re: 'openssl speed' and ENGINE
At 07:14 PM 10/2/01 +0100, Ben wrote:
>Tom Biggs wrote:
> >
> > I'm trying to get a handle on how fast our crypto engine is,
> > so I'm running 'openssl speed xxx -engine yyy'.
> >
> > Can someone explain the difference between normal timing and
> > '-elapsed' timing? It's giving me wildly different results
> > and I would like to understand why. When I do '-elapsed' with
> > the software vs. my hardware, it shows the hardware as being
> > _much slower_, so clearly I'm missing something.
>
>Normal timing measures the CPU used, which is typically very little for
>hardware. Elapsed is what it says, but obviously has problems unless the
>machine is unloaded.
I meant to ask about CPU time - it looks like the ops/second is
determined from (#ops)/(CPU time), so it would wildly inflate the
number. In some sense it's true that the CPU could be off doing
something else instead of cranking out modexps. But I am trying
to get hard numbers for the real number of ops per second.
That's why I was messing with elapsed time.
I'm running my tests on an otherwise unloaded 733 Pentium.
>BTW, it isn't unheard of for hardware to be slower that software - some
>is that way by design (it can do lots of parallel operations, but
>openssl speed doesn't test that) and some is that way because people set
>their targets by benchmarking other software - some of which is vastly
>slower than OpenSSL.
>
>What hardware have you got?
Newly developed hardware I've just done an ENGINE for. It's not
set up for concurrent operations right now. We didn't set any
targets, we just designed a modexp the best we knew how.
Is -elapsed the way to go to get the real #ops/second?
If so, I've got a lot of work to do, because like I said, it says
the hardware is slower than the software. And that would be ugly.
Though I do have work to do in optimizing the support lib / driver.
Tom Biggs
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
