When using zEDC with XCOM transfers, having time and CPU issues.
We ran 2 jobs. One with COMPRESS=ZLIB and one with COMPRESS=NO.
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.
Release : 12.0
Component : XCOM Data Transport for z/OS
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
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.
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.