Measuring CA Datacom® Symmetrical Multiprocessing and the IBM z Integrated Information Processor (zIIP)
By Kevin Shuma – November 2020
In earlier posts (Introduction to CA Datacom® and the IBM z Integrated Information Processor (zIIP) and Understanding CA Datacom® Symmetrical Multiprocessing and the IBM z Integrated Information Processor (zIIP)), we discussed the delivery of the IBM zIIP processor and its exploitation in the CA Datacom Multi-User facility (MUF) using Symmetric Multiprocessing. In this post, we discuss various ways that you can collect statistics on zIIP use in the MUF.
There are two basic ways to measure zIIP usage within the MUF – Internal and External.
Internal measurements are provided from within the MUF address space. Internal measurements are based on the MUF’s internal calculations of processing that is zIIP eligible and the amount of processing that is actually dispatched to a zIIP processor.
External measurements are provided by external monitors that collect information on the MUF address space while it is executing. These monitors see the MUF address space as a single operating entity and provide overall CPU usage (zIIP and GP).
Internal/External Measurements – At this time, two MUF related processes can be used to generate a report that shows both the internal measurement from the MUF and the external measurement collected by the MUF by issuing a special operating system command. Presently for performance reasons, this external measurement information is only collected when:
- Requested by the user by issuing the MUF console command ALL_INFO_REPORT
- The MUF address space comes to a normal end of job.
Internal measurements are based on the data found in the Dynamic Systems Tables (DST) database. The information provided in the DST database is from the time the MUF was initiated. Each subsequent query against the DST database provides measurements since the initiation of MUF. Therefore, most measurements continue to increase over time.
Currently, the DST table MUF_SRB_ZIIP provides the information on zIIP eligibility and utilization by the tasks running in the MUF address space. The specific types of tasks and their zIIP eligibility were discussed in the earlier post about Understanding CA Datacom® Symmetrical Multiprocessing and the IBM z Integrated Information Processor (zIIP).
To determine the amount of CPU seconds offloaded to the zIIP processor add up the CPU seconds consumed on tasks with the type SMP *SRB-SMP. These tasks only exist in a MUF started with the option SMPTASK n,n,n,SRB. CPU seconds used for the other tasks in the MUF are GP CPU seconds.
There are multiple ways to extract the zIIP offload information from the DST database:
- Execute a DBUTLTY batch job with the AUTOINFO DDNAME=DUMMY control card
- Execute a DBSQLPR batch job with an SQL query extracting information from the DST database table MUF_TCB_OR_SRB
- Perform a normal shutdown of the MUF address space which generates a report to SYSPRINT containing the MUF_TCB_OR_SRB information
- Issue a DCTCBSRB command against a selected MUF address space for sites with the CA SYSVIEW Option for CA Datacom.
Each of the above options, access the information in the DST database table MUF_TCB_OR_SRB and display the data in a similar fashion. For the following section, we use the data as displayed in the DBUTLTY AUTOINFO report. The report examples shown next provide snapshots of information for different MUF implementations with and without zIIP eligibility.
The processing workload in the MUF has been repeated in each case to get a consistent workload for the measurement.
Report for a MUF address space not executing in Symmetrical Multiprocessing mode. No zIIP eligibility.
Total CPU consumed 191 seconds – all GP, no zIIP offload.
Report for a MUF address space executing in Symmetrical Multiprocessing mode without SRB tasks activated (SMP TASK 3,2,4,TCB ). No zIIP eligibility.
Total CPU consumed 185 seconds, all GP no zIIP offload.
Report for a MUF address space executing in Symmetrical Multiprocessing mode with SRB tasks activated (SMP TASK 3,2,4,SRB ). Activated with zIIP eligibility.
Total internal CPU consumed 208 seconds.
- GP CPU – 19 seconds
- zIIP CPU – 189 seconds.
When dividing the zIIP CPU consumed by the total CPU consumed, we calculate the zIIP offload as 91% (internal measurement).
In the three examples above, we executed the same workload against the MUF address space. We see that in the zIIP eligible case the total CPU grew by 23 CPU seconds, but the GP CPU consumption dropped by 166 seconds. While the zIIP offload was 91%, the GP CPU savings was about 90%.
External measurements are based on the data retrieved by using external tools while the MUF address space is executing. These measurements are based on the CPU data collected from the z/OS address space. The information is done at a GP CPU and zIIP CPU level. The information is not broken down into individual SRB/TCB tasks.
These monitors provide information about CPU consumption from an external point of view from the initiation of the MUF address space. These measurements include MUF start-up and any “other processing” done by the operating system to support the address space up to this point. These additional CPU charges show that the externally measured processing is higher than the internally measured processing. In addition, most of the “other processing” is not zIIP eligible, which lowers the zIIP offload percentage.
In some cases, the difference in zIIP offload between internal and external measurements could be as much as 10%. In most cases, the difference is around 5%.
When available, the externally measured zIIP offload percentage should be used as the “true” zIIP offload.
There are multiple external monitors that can be used to display the MUF address space GP and zIIP CPU usage. These include TSO/ISPF, CA SYSVIEW SDSF, RMF and many others. Additionally, when a job ends, the JESLOG information typically includes statistics on CPU usage.
In the following examples, we are using externally collected data displayed by the CA SYSVIEW SDSF DISPLAY ACTIVE (DA) display. The SYSVIEW DA display includes columns of information for total CPU consumed and zIIP CPU consumed that we selected for display:
- CPU-Time – total CPU (GP and zIIP) consumed by the address space
- CPTime – amount of GP CPU consumed by the address space
- IIPtime – amount of CPU executed on a zIIP processor
- IIPonCP – amount of CPU dispatched for zIIP but redirected to a GP CPU because the zIIP was not available
- IIPencl – amount of CPU that was zIIP processor eligible should be the total of IIPtime plus IIPonCP.
The report examples shown next provide snapshots of information for different MUF implementations with and without zIIP eligibility. The processing workload in the MUF has been repeated in each case to get a consistent workload for the measurement.
Report for a MUF address space not executing in Symmetrical Multiprocessing mode. No zIIP eligibility.
Total CPU consumed 208 seconds (3:28) – all GP, no zIIP offload.
Report for a MUF address space executing in Symmetrical Multiprocessing mode without SRB tasks activated (SMP TASK 3,2,4,TCB ). No zIIP eligibility.
Total CPU consumed 201 seconds (3:21) – all GP, no zIIP offload.
Report for a MUF address space executing in Symmetrical Multiprocessing mode with SRB tasks activated (SMP TASK 3,2,4,SRB ). Activated with zIIP eligibility.
Total external CPU consumed 222 seconds (3:42).
- GP CPU – 34 seconds (0:33.68)
- zIIP CPU – 189 seconds (3:09).
When dividing the zIIP CPU consumed by the total CPU consumed we calculate the zIIP offload as 85% (external measurement).
In these three examples, we executed the same workload against the MUF address space. In the zIIP eligible case we saw the total CPU grow by 21 CPU seconds, but the GP CPU consumption dropped by 168 seconds. While the zIIP offload was 85%, the GP CPU savings was about 84%.
Internal/External measurements are based on the information that is found in the DST database tables and the information that is collected by triggering the MUF address space to issue a z/OS command to capture the externally measured CPU usage.
As we discussed previously, the two ways to get this combined information is to issue the MUF console command ALL_INFO_REPORT or to terminate the MUF address space normally.
Note: To use the ALL_INFO_REPORT console command, the MUF address space must be started with the PXX information written to a SYSOUT dataset (see MUF Startup Option SYSOUT).
In both cases, a report is generated with multiple pages of statistics. The page entitled TCB/SRB USE SUMMARY INFORMATION provides the TCB and SRB CPU usage (internal measurement) down the page and the internal and external total measurements at the bottom of the page.
The bottom left provides the total internal CPU while the bottom right provides the total external CPU usage.
Report for a MUF address space not executing in Symmetrical Multiprocessing mode. No zIIP eligibility.
Total internal CPU consumed 192 seconds (3:11.93) – all GP, no zIIP offload.
Total external CPU consumed 209 seconds (3:28.91) – all GP, no zIIP offload.
Report for a MUF address space executing in Symmetrical Multiprocessing mode without SRB tasks activated (SMP TASK 3,2,4,TCB ). No zIIP eligibility.
Total internal CPU consumed 185 seconds (3:05.14) – all GP, no zIIP offload.
Total external CPU consumed 202 seconds (3:21.70) – all GP, no zIIP offload.
Report for a MUF address space executing in Symmetrical Multiprocessing mode with SRB tasks activated (SMP TASK 3,2,4,SRB ). Activated with zIIP eligibility.
Total internal CPU consumed 209 seconds (3:29.02).
- GP CPU – 20 seconds (0:19.85)
- zIIP CPU – 189 seconds (3:09.17) zIIP offload as 90% (internal measurement)
Total external CPU consumed 223 seconds (3:42.86).
- GP CPU – 34 seconds (0:20.26 + 0:13.42)
- zIIP CPU – 189 seconds (3:09.17) zIIP offload as 85% (external measurement)
How can I estimate zIIP offload if I do not have a zIIP processor available? Use any of the available internal measurement processes to estimate the amount of the MUF processing that would be eligible to offload to zIIP processors when running the MUF address space executing in Symmetrical Multiprocessing mode with SRB tasks activated (SMP TASK 3,2,4,SRB ).
The following AUTOINFO report shows the MUF address space executing in Symmetrical Multiprocessing mode with SRB tasks activated (SMP TASK 3,2,4,SRB ) without a zIIP processor available.
In this example, the *SRB-SMP tasks are still present and active. These tasks represent the processing that could have been sent to a zIIP processor. In this case, we would estimate the zIIP offload as 164/187 or about 87% (internal measure).
If we compare this back to the numbers from similar executions of the same workload with a zIIP processor available, the offload percentages for internal measurements are about the same.
In summary, there are multiple tools available both inside and outside of CA Datacom that you can use to measure the amount of zIIP utilization. The tools that come from inside Datacom provide a greater level of detail as they display usage by the various active tasks within the MUF address space. The tools that measure the CPU usage externally do not provide the same level of granularity as the internal MUF tools, but they represent more complete measurements as they include all CPU time spent to support the MUF address space including start-up and shutdown activities.
This document was created using a test system on a lightly loaded z/OS LPAR with a fixed/repeatable workload. The workload was a reasonable mix of both read and heavy maintenance processing that would typically be seen in the normal end-of-day batch processing cycle. While we believe it to be an accurate representation of the typical zIIP offload processing for a 15.1 MUF address space at most sites, it is a best effort estimation.
Many factors (both internal and external to the MUF address space) can affect the measured zIIP offload percentage at a site. We tried to consider these in our recommendation, but each site might experience different results due to these factors.
One final thought: The IBM zIIP processors run at full processor speed, which means that they might actually be able to process more workload per CPU second (MIPS) than a GP CPU that is running in a constrained or reduced CPU capacity. As such, moving workload to a zIIP processor might actually account for more offload than is measured in the simple offload calculations as shown above. However, since these types of calculations could get quite complicated, using a simple formula as proposed above gives a reasonable estimate that can be used to measure and track zIIP exploitation as the site makes changes and improvements in their environment.