zEDC and IBM Sterling Connect:Direct for z/OS

Long before zEDC, IBM Sterling Connect:Direct for z/OS (CDzOS), a managed file transfer product specializing in sending z/OS datasets from one mainframe customer to another, supported compressing a file before transmitting it. It originally only supported simple “prime character” compression, whose primary technique is to collapse a repeating string of the chosen character, usually a blank, into that character and a multiplier. Later, LZW compression was added, and then ZLIB. Unfortunately, before implementing any of these methods in production, you needed to do a careful cost-benefit analysis of elapsed time, CPU time, and TCP I/O time. zEDC changed all that. Now it’s almost a no-brainer – use zEDC compression when transmitting files of any significant size, or else you are probably paying and waiting too much.

In the late 1990’s, network pipes were thinner than today, often making the elapsed time an issue, since the longer the connection, the more pain points (both internal and external) could be encountered. Besides time lost resending dropped packets as line quality varied during a transmission, the longer the transmission, the greater the chances of losing the connection altogether. CDzOS automatic checkpoint restart helped for the latter case, but if the checkpoint interval was too large a checkpoint restart could be tantamount to restarting from the beginning, and if the interval was too small, performance could be degraded. It often made sense to compress to alleviate network congestion, even though the cost in CPU was considerable for ZLIB. As the 2000’s progressed, the balance shifted as pipes grew fatter. The primary bottleneck increasingly became the CPU, not the network or file I/O. One way to cope was to pre-compress the file to avoid holding a session open while the CPU compressed data. CDzOS standalone ZLIB compression was added around 2001. But the inconvenience of the added step outside of CDzOS relegated it mainly to the rare “compress once, send many” scenarios. By 2010, many CDzOS customers wanted to use ZLIB compression, but they considered it too much of a CPU hog. Large dataset transfers would take many times as long with ZLIB than with no compression due to increased CPU time, which, unlike I/O, was unavoidably synchronous. Then zIIP support was added to CDzOS, which allowed the CPU time to be offloaded to a zIIP processor. But it also adds some overhead to schedule SRBs, and sometimes contention for zIIP processors could add more delay. In fact, using zIIP rarely saves time (it only can save time if the GP CPUs are kneecapped, since zIIPs are not) and so it didn’t reduce the exposure to line conditions. zEDC changed all that by not only offloading the compression CPU time to the accelerator, but it also greatly reduced the amount of data sent. Although the accelerator still needed time to compress, and so individual transmissions could still take extra time (though nowhere near the extra time needed for non-zEDC ZLIB compression), it dramatically reduced the impact of bulk file transfer on both CPU and the network.

In a simple test on our z13, I copied a 2-stripe 9 GB file from one LPAR to another 2-stripe 9 GB file on another LPAR in the same z13, using TCP. First, I copied without compression, then with prime compression, then with unassisted (“software”) ZLIB, then with zEDC assisted ZLIB. Elapsed time is unrealistically low with all these tests. In real world situations, going through the internet will add elapsed time, proportionate to the number of bytes actually transmitted.  

I ran each COPY three times. Here are the best results as reported by the CDzOS address space (note this does not include the impact on the TCPIP address space which also incurs CPU and IO service).

As you can see, prime compression doesn’t always do well. In this case blanks were the prime character and there were no blanks in the data. The non-prime compression part of the algorithm was only able to reduce the size of the transmission by 8%, but at a large CPU cost. This underscores the need to know your data and your compression algorithm before attempting compression. Prime compression is not a very good algorithm for many data sets.

COPY with software ZLIB compression took 257% more elapsed time than COPY with no compression, but being a much better algorithm than prime compression, ended up transmitting only 17% of the original size. Software ZLIB took 30 times the send side CPU and 8 times the receiving side CPU compared to uncompressed, which is on par with prime compression. But on average it does a much better job of compressing than prime compression, especially when you don’t know your data.

COPY with the z13’s zEDC accelerator card assisted compression took 5% more elapsed time than COPY with no compression, and more than twice as much (of a very small amount of) CPU. Happily, it compressed the data set to only 22% of the original size. This is makes zEDC compression economical in any scenario that sends data out through the internet. It beats software ZLIB hands down, unless you are not charged for CPU. Note that though the z13 accelerator compression is much faster than software ZLIB, it compresses slightly less. However, hardware improvements have reduced this disadvantage. On our z15, the zEDC accelerator (now on a chip) compresses the same data set to 1,751,082,751 bytes, or 19% of the original size.

So now, thanks to zEDC, the question of whether to compress or not boils down to the following. If you are being charged for TCP, compress your data. If you are being charged for CPU or time is of the essence, use zEDC. If you are not being charged and elapsed time is irrelevant, do what makes you happy (having all the time in the world and not being charged go a long way towards making me happy). Under no circumstances should you use software ZLIB compression unless consuming mass quantities of CPU makes you happy. IMO, it’s better to forgo compression altogether than use software ZLIB (which is what I often recommended in the decade before zEDC). With zEDC, CDzOS is less complicated, less expensive, and faster.

Originally published on the IBM Z and LinuxONE Community Blog.