Elapsed time and CPU Usage Problems Using zEDC with XCOM

Products

• XCOM Data Transport
• XCOM Data Transport - z/OS
• XCOM - SUPPORT

Issue/Introduction

When using zEDC with XCOM transfers, having time and CPU issues.

We ran 2 jobs.  One with COMPRESS=ZLIB and one with COMPRESS=NO.

1. The ZLIB job receives the following message:

XCOMM0934I zEDC hardware acceleration will be used for compression
XCOMM0373I ..............65915 BLOCKS .............287639 RECORDS SENT

The ZLIB job used 51.56 CPU minutes and 79.5 minutes elapsed time.

      2. The COMPRESS=NO job shows the following:

XCOMM0137I .............287639 RECORDS SENT

The COMPRESS=NO job used 0.23 CPU minutes and elapsed time was 4.1 minutes.

Why is the zEDC transfer using so much CPU and time?  

Environment

Release : 12.0

Component : XCOM Data Transport for z/OS
IBM

Cause

This comparison as outlined here is not meaningful.  It compares COMPRESS=NO to COMPRESS=ZLIB with zEDC.
Using any form of compression will naturally introduce overhead when compared to using no compression at all.  In most cases,
compression actually has a net negative impact on CPU consumption and transfer performance, given the speed of modern networks.
It is important to note that zEDC does not provide CPU-less compression, and that there can be significant caveats associated with 
using it.

Resolution

The only valid comparison that can be made for zEDC performance would be between a transfer using COMPRESS=ZLIB both with and 
without the zEDC hardware assist.

As far as giving an account for the CPU required to use ZLIB with the zEDC assist, that would need to be pursued with IBM. The following is our methodology for invoking ZLIB on a processor which has the zEDC configured and available.  Most of these processes are documented in the IBM Redbook for using hardware-assisted compression.

1. During XCOM startup, XCOM makes iterative calls to the IBM-supplied functions inflateHwAvail and deflateHwAvail in order to determine what the configured minimum buffers are in order to invoke zEDC. These values are then displayed in message XCOMM0935I - in this case 4k for deflate (compress) and 16k for inflate (decompress).
   
   
2. If a transfer's network buffer size satisfies the configured minimums to use zEDC, XCOM then invokes the IBM-supplied version of zlib functions which contains specialized code to drive the hardware assist.  Note that the IBM version of zlib is version 1.2.7 and requires a Language Environment, while the version of zlib used by XCOM for running on zIIP is 1.2.8 and does not use a Language Environment.
   
   
3. In the event an individual buffer (any time during the transfer) falls short of the minimum required for zEDC, the ENTIRETY of the remaining portion of the compression calls will be processed as SOFTWARE compression, and the hardware assist will not be used again during the life of the transfer.  This is determined by the IBM-supplied zlib functions themselves.  XCOM has no involvement in this determination.  (This can be validated by turning XCOM tracing for the transfer, in which you can see each buffer's compression call result that indicates whether the compression was performed by hardware, or if it was deferred to software.)

Questions regarding good or bad performance as it relates to the usage of zEDC should be sent to IBM.  Questions about how/why it's working a particular way should be accompanied with XCOM trace results that show for each buffer being compressed whether the hardware compression assist was actually being used.