Transferring data from a PC to the host using the network—which is complex, with many hops between the PC and the host—showed no throughput increase by enabling ibmca, but host CPU usage during the transfer dropped dramatically, from about 70 percent to 15 percent. This suggested a network bottleneck; repeating the test using SCP within the Linux host, using “localhost” as the target address and /dev/null as the output, increased throughput when ibmca was enabled.
Since CPACF doesn’t support all ciphers and Message Authentication Codes (MACs), it’s important to select appropriate ciphers and MACs; SCP allows specification of both.
We performed more tests using various ciphers: Triple DES, AES-128, AES-192 and AES-256, all of which benefit from CPACF. The MD5 MAC is always executed in software on System z, since CPACF doesn’t support it, whereas SHA-1 can also benefit from CPACF. Figure 7 shows the results of operations with and without dynamic engine loading support active using TDES and AES ciphers and MD5 and SHA-1 MACs. The user time of the execution of the scp command is an indication of the CPU cycles consumed. It’s clear that CPACF dramatically decreases CPU consumption for TDES and AES. MD5 is the faster MAC in software, but with CPACF, SHA-1 contributes to another 30 percent gain. Using CPACF clearly frees up cycles that can be used for other workloads.
Determine Ciphers/MAC Via Profile
Most SSH or SCP users won’t explicitly specify the cipher or MAC, so it’s worth considering modifying the configuration files for the Linux SSH client (ssh_config) and SSHD server (sshd_config) to default to using algorithms that will benefit from hardware crypto support. Using the Ciphers and MACs keyword lets you specify the algorithms that will benefit from hardware at the top of the search order: AES or TDES as the top cipher, and SHA as the top MAC. If the hardware is System z9, choose TDES or AES-128 rather than AES-192 or AES-256 because the latter two aren’t supported by CPACF until z10.
Influence of Crypto Express
Having a Crypto Express feature helps during session initialization for asymmetric RSA requests. The SCP test represents a relatively long-running session with only one RSA handshake, so the effect of an active Crypto Express feature was minimal (a difference of 0.01 seconds for user time). The benefit of a Crypto Express feature for OpenSSH is greater if a high number of short-running sessions are established simultaneously, as is common with some Web applications.
Using hardware encryption support in combination with OpenSSH can save significant CPU cycles, leading to better performance. At a minimum, CPU load will decrease for encryption workloads. Tests indicated a user time reduction for TDES by a factor 15 and a factor of 11 for AES. Selecting SHA as MAC also was beneficial. Use of CPACF is free of charge and its enablement is strongly encouraged. If a Crypto Express feature is available, make it available to Linux systems that can benefit from it.