> Of course your CPU is a lot slower to perform 2048 signs, but it's a lot faster to perform one. I mean if you simply don't get more than 1 sign request within 240ms and if you insist on always using GPU, you'd have to ask it to perform 1 real and 2047 bogus signs. And so you'll have GPU spending 240ms on one sign instead of having CPU spending portion of millisecond. Resulting in ... lower throughput.
Absolutely, although I'm not convinced you actually get lower throughput, just lousy latency; remember, requests can pile up during your 240ms, so the next batch is fuller. As you say, a good solution would transition from CPU to GPU at (or near) the point of CPU exhaustion; this sounds fairly simple to implement given an asynchronous API. The obvious application is web serving, which I assume (perhaps naively) accounts for a substantial majority of private decrypts performed using openssl, is fairly tolerant of latency, and potentially very hungry for throughput. People buy SSL accelerator cards for a reason, right? Cheers Eben ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
