On Thu, Oct 23, 2008 at 4:52 PM, Marcy Cortes <[EMAIL PROTECTED]> wrote:
> Yes. Configured as accelerators. > > No figures. There isn't a velocity report on them (no monitor data > perhaps?). But the comments from the applications folks was "pretty > close" to non-SSL. Benchmarking it is not trivial (appears not even trivial to ensure they are used). And there's a trade-off to be made in configuration. The idea is that you offload work to the crypto processor. So after you started the work, the CPU must go back to get the results. As it turns out, the resolution of the Linux timer is such that it may take longer than when you would emulate it in software. So while you save resources on a global level, measuring a single thread doing these encryption operations will not show you that in elapsed time. You'd need enough parallel threads all doing encryption to show the difference. To address the customer disappointed caused by this, developers added the option to let the CPU poll (busy wait) for the crypto. For a single thread, that means you can run the crypto operations quicker after each other. As long as the device is faster than software emulation, you still save CPU although not as much as without polling. So you pay a price to reduce latency. When you have multiple threads going for the crypto, you get a queue and operations may take longer than when you did them yourself. With all waiting threads spinning for the answer, it also takes more resources then when you did it in software. I'm not sure what the default is. With the breakdown of CPU usage per process in Linux, you should be able to see the sweet spot in your benchmark when you increase the number of threads. -Rob ---------------------------------------------------------------------- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
