>Consider the cost of a CEX operation as ((ICSF call CPU)+I/O) and the cost of >a >CPACF operation as ((ICSF call)+(some >CPU cycles for the operation)). So the >difference is I/O vs. CPACF cycles. The I/O cost doesn't change (much) with >larger >blocks; the CPACF cycles do.
This statement implies that CPACF REQUIRES ICSF. That is NOT true. You can happily do CPACF operations yourself without ICSF even configured on the system. IBM's white papers about CPACF performance indicate that ICSF imposes a big performance hit on CPACF. Lloyd ----- Original Message ---- From: Phil Smith <p...@voltage.com> To: IBM-MAIN@LISTSERV.UA.EDU Sent: Fri, July 6, 2012 3:32:01 PM Subject: Re: Secure Encryption Keys vs Protected Keys R.S. wrote: >Protected key means CPACF in use, secure key means CryptoExpress card. >The difference can be 1000 times or 10 times. Of course CPACF is always >faster. >The more cpu-intensive algorithm and the smaller block of data to be >encrypted, the bigger difference is. I think the second sentence is confusing here-not saying it's wrong, just that I can read it a couple of ways, due to English's inherent lack of clarity (not your fault, Radoslaw!). For very large blocks of data, on very CPU-constrained systems that have relatively low CEX use, CEX should be faster relative to CPACF than on less CPU-constrained systems. That is, you look at the CEX interaction as an I/O and CPACF as something that uses some of the "real" CPU as well as being somewhat offloaded, then if "real" CPU is at a premium, and the blocks are large, the cost of the I/O becomes smaller (relatively) than in a less-constrained case, or one with smaller blocks. Consider the cost of a CEX operation as ((ICSF call CPU)+I/O) and the cost of a CPACF operation as ((ICSF call)+(some CPU cycles for the operation)). So the difference is I/O vs. CPACF cycles. The I/O cost doesn't change (much) with larger blocks; the CPACF cycles do. Thus with large blocks, CEX will still be slower than CPACF, just (somewhat) less noticeably so. I had a customer claim CEX could actually be faster in some cases, but they didn't have data to back it up, so I don't believe him (I don't disbelieve him either-more of a Schrödinger's cat deal). -- ...phsiii Phil Smith III p...@voltage.com<mailto:p...@voltage.com> Voltage Security, Inc. www.voltage.com<http://www.voltage.com/> (703) 476-4511 (home office) (703) 568-6662 (cell) ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
