Using zEDC with CA XCOM

book

Article ID: 193819

calendar_today

Updated On:

Products

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

Issue/Introduction

Trying to use zEDC with XCOM transfers but having runtime and CPU issues.

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

The ZLIB run 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.

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.


What's wrong with the zEDC transfer?  


Environment

Release : 12.0

Component : CA XCOM Data Transport for z/OS

Resolution

Unfortunately, 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.  For most customers,
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.

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, we make 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 it is determined that a transfer's network buffer size satisfies the configured minimums to use zEDC, we then invoke 
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 Envorinment, while the version of zlib used by XCOM for running on 
zIIP is 1.2.8 and does not use a Language Envorinment.

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.)

Thus, any questions about 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.