Hi Renato, Did you notice this statement at the beginning of the IQPPRM* chapter in the init and tuning reference for z/OS 2.5...
Note: The IQPPRMxx will still be valid on IBM zEnterprise z15 and above processors, but the tunable options will no longer be available. Therefore, a message IQP062I REQUEST REJECTED - OPTIONS IGNORED will be displayed. I am not sure what it means exactly, however I'd be inclined to check the log for IQP062I messages. It sounds as though the IQP parms may not even be honored. I have little experience with on-chip zEDC, but did some benchmarking with the first round of PCIe zEDC adapters. For that world the DEFMINREQSIZE and INFMINREQSIZE values you're using seem exceedingly small, and allow for inefficient zEDC processing of smaller data quantities. Of course, on-chip zEDC will be faster than PCIe zEDC, but it is not clear/documented how this would impact settings of the minimums, especially on a z15 which may just give you some sort of parameter toleration mode. If the tiny default inflate and deflate minimums are being used, the overhead associated with Huffman compression/decompression will drive up CPU and provide reduced compaction, assuming the actual amount of in buffer data is also quite small. While not sure if on-chip zEDC versus PCIe zEDC is apples to apples, our limited benchmarks about 5 years ago compared CPU consumption for hardware assisted (CMPSC) compression against zEDC and against no compression. We found that for record sizes of... 512 bytes, zEDC used appx 250% more CPU than CMPSC, and appx 450% more CPU than no compression 1024 bytes, zEDC used appx 20% more CPU than CMPSC, and appx 225% more CPU than no compression 2048 bytes, zEDC used appx 30% less CPU than CMPSC, and appx 60% more CPU than no compression 4096 bytes, zEDC used appx 130% less CPU than CMPSC, and appx same CPU as no compression 8192 bytes, zEDC used appx 300% less CPU than CMPSC, and appx 20% less CPU than no compression 16K bytes, same as above Unfortunately I do not know what the IQP minimum values were set at for the above test at this point in time, but guessing in the neighborhood of 4-8K. So at some point, probably below the 4-8K range, the relative inefficiency of software level compression is reflected. Okay, just checked the z/OS 2.5 MVS callable services doc for high level languages, chapter 14, pg 195 and it documents things more clearly... 4. Ensure that adequately sized input buffers are available. If the input buffer size falls below the minimum threshold, data compression occurs using zlib software compression and not zEDC. Note: IBM zEnterprise z15 and above processor thresholds will no longer be tunable through parmlib. The IQPPRMxx will still be allowed in the configuration, but the values will no longer be accepted. The environment variables _HZC_DEFLATE_THRESHOLD and _HZC_INFLATE_THRESHOLD can also be used to control the threshold for going to zEDC. The valid values are in the range 1-9999999. According to the above, you're IQP parms are being ignored and you will need to use the environment variables they mention. No mention of an equivalent for the MAXSEGMENTS parm. If you end up trying out the above env vars, I'd definitely appreciate an email with your results as this is something I've wondered about. HTH, Mike -----Original Message----- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Compagno Renato (Consulente per BCC Sistemi Informatici) Sent: Tuesday, March 22, 2022 11:41 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: R: zEDC compression on z14 and z15 by using ADRDSSU Caution! This message was sent from outside your organization. Hi Chuck, PRDB 2022081 16:09:11.83 -D IQP PRDB 2022081 16:09:11.83 IQP066I 16.09.11 DISPLAY IQP 681 zEDC Information DEFMINREQSIZE: 1K (STATIC) INFMINREQSIZE: 1K (STATIC) Feature Enablement: Enabled PRDB 2022081 16:31:19.36 -D PROD,STATE,FEATURENAME(ZEDC) PRDB 2022081 16:31:19.37 IFA111I 16.31.19 PROD DISPLAY 195 S OWNER NAME FEATURE VERSION ID E IBM CORP z/OS ZEDC * .* .* 5650-ZOS On joblog we can see: 01.52.58 INTERNAL VAMMSG DATASET DR.DUMP.D220208.T160612.JF2068 ALLOCATE ON VAM STORAGE GROUP 01.52.58 JOB01194 IEF233A M F8A7,PRIVAT,SL,PSDRB112,DUMP021, 269 269 DR.DUMP.D220208.T160612.JF2068 01.52.58 JOB01194 ADR111I-SET PATCH 0D=FF 278 01.52.58 JOB01194 ADR111I-SET PATCH 0E=3C 279 01.52.58 JOB01194 ADR111I-SET PATCH 0F=0A 280 01.52.58 JOB01194 ADR533I (004)-ZCOMP(01), 2022.040 01:52:58 ZEDC SERVICES TO BE USED FOR 281 281 DUMP DATA SET ON DDNAME N1 01.52.59 JOB01194 IECTMS9 F8A7,F03394,PSDRB112,N1 ,2022/045 ,00001,08.T160612.JF2068 01.53.00 JOB01194 IEC705I TAPE ON F8A7,F03394,SL,COMP,PSDRB112,DUMP021,DR.DUMP.D220208.T160612.JF2068,MEDIA2 01.54.38 JOB01194 IEC205I N1,PSDRB112,DUMP021,FILESEQ=1, COMPLETE VOLUME LIST, 465 465 DSN=DR.DUMP.D220208.T160612.JF2068,VOLS=F03394,TOTALBLOCKS=10788 01.54.39 JOB01194 IEF234E K F8A7,F03394,PVT,PSDRB112,DUMP021 01.54.39 JOB01194 TMS014 IEF234E K F8A7,F03394,PVT,PSDRB112,DUMP021 01.54.39 JOB01194 -PSDRB112 DUMP021 00 20957 .21 .01 1.68 640K 0 0 0 0 0 22 -----Messaggio originale----- Da: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> Per conto di Chuck Kreiter Inviato: martedì 22 marzo 2022 15:23 A: IBM-MAIN@LISTSERV.UA.EDU Oggetto: Re: zEDC compression on z14 and z15 by using ADRDSSU Have you confirmed the feature is installed and all parms set properly? It almost appears it's GP's instead of zEDC. -----Original Message----- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Compagno Renato (Consulente per BCC Sistemi Informatici) Sent: Tuesday, March 22, 2022 3:58 AM To: mailto:IBM-MAIN@LISTSERV.UA.EDU Subject: I: zEDC compression on z14 and z15 by using ADRDSSU Sorry guys I realized that the table have lost their format then I resend them and I hope this will enhances the readability Jobchain On Z14 with ZCOMP: JOBNAME Step CPU SRB Count Min. Min. PSDRB101 142 26.56 0.58 PSDRB102 142 26.34 0.58 PSDRB103 142 25.7 0.56 PSDRB104 142 25.6 0.56 PSDRB105 142 25.63 0.58 PSDRB106 142 25.4 0.53 PSDRB107 142 25.81 0.54 PSDRB108 142 25.84 0.54 PSDRB109 141 25.35 0.53 PSDRB110 141 25.21 0.52 PSDRB111 141 25.58 0.55 PSDRB112 141 25.7 0.54 PSDRB113 141 25.66 0.6 PSDRB114 141 25.77 0.57 PSDRB115 141 25.96 0.57 PSDRB116 141 26.03 0.6 PSDRB117 141 26.36 0.6 PSDRB118 141 26.94 0.62 PSDRB119 141 26.72 0.62 PSDRB120 141 26.51 0.6 PSDRB121 141 26.8 0.59 PSDRB122 141 26.34 0.58 PSDRB123 141 25.87 0.54 PSDRB124 141 25.21 0.5 PSDRB125 141 25.64 0.55 PSDRB126 141 26.2 0.56 PSDRB127 141 26.41 0.6 PSDRB128 141 26.06 0.55 PSDRB129 141 26.63 0.59 PSDRB130 141 26.62 0.61 Totale 4238 780.45 17.06 Jobchain on Z15 with ZCOMP: JOBNAME Step CPU SRB Count Min. Min. PSDRB101 143 54.64 2.29 PSDRB102 143 55.02 2.38 PSDRB103 143 54.21 2.24 PSDRB104 143 54.55 2.32 PSDRB105 143 54.97 2.34 PSDRB106 143 54.41 2.34 PSDRB107 143 53.98 2.26 PSDRB108 143 54.54 2.32 PSDRB109 143 54.81 2.39 PSDRB110 143 54.46 2.3 PSDRB111 142 53.6 2.29 PSDRB112 142 53.68 2.28 PSDRB113 142 52.73 2.28 PSDRB114 142 52.99 2.25 PSDRB115 142 54.31 2.35 PSDRB116 142 54.89 2.38 PSDRB117 142 54.97 2.43 PSDRB118 142 54.77 2.37 PSDRB119 142 55.12 2.44 PSDRB120 142 54.81 2.37 PSDRB121 142 53.84 2.33 PSDRB122 142 54.72 2.37 PSDRB123 142 55.38 2.41 PSDRB124 142 54.15 2.32 PSDRB125 142 54.83 2.34 PSDRB126 142 54.41 2.35 PSDRB127 142 54.5 2.27 PSDRB128 142 55.06 2.35 PSDRB129 142 54.3 2.28 PSDRB130 142 54.52 2.22 Total 4270 1633.17 69.86 As we can see : 1. We built dynamically 30 jobs per days with 141/142/143 steps each one (1 step → 1 DASD dumped) 2. We had some more steps on the second run because the numbers of DASD devices has increased meanwhile; 3. The CPU consumption is equivalent per job on each job chain (it means that the content of the DASD didn’t influence the CPU utilization: do you agree?) 4. In total on Z15 we used the CP for (1633.17 +69.86) minutes and on Z14 for (780.45+17.06) minutes the difference is 905 minutes → more than 15h of 1 CP per day! This is an huge increase (especially if you pay the SW fee based on the total CPU utilization)! 5. We relieved this behavior only for the DUMP with DFDSS by using ZCOMP DISK to TAPE (not for the compression on DISK via dataclass for example) 6. We relieved on Z15 an elapsed time reduction and maybe also in the compression ratio has been reduced but this is not the point I raised up . The point is that on Z15 we experienced more CPU consumption and IBM said: "The Integrated Accelerator for zEDC, available with IBM(r) z15(tm) ..., reduces the cost of storing, transporting and processing data. It replaces the zEDC Express adapter with on-chip compression, providing increased throughput and capacity: for the z15, up to 8 times faster application elapsed time with no additional CPU time compared to a z14 with zEDC Express for compression and decompression (cfr https://www.ibm.com/support/z-content-solutions/compression/)" Unfortunately I do not have the Z14 anymore and I can’t do further tests. Ciao Renato ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to mailto:lists...@listserv.ua.edu with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to mailto:lists...@listserv.ua.edu with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
