z/OS V1R6 LSPR FAQ 

 Question: 

What are the major changes to the z/OS V1R6 LSPR for the IBM System z9 109?

 Answer: 

 The LSPR ratios reflect the range of performance between prior zSeries servers and the z9-109 as measured using a wide variety of application benchmarks. The latest release of LSPR contains a number of updates to reflect the continuing evolution of zSeries client applications and configurations. First, the workload suite has changed: the short running batch workload (CB-S) is replaced with a Java based batch workload (CB-J). Second, all workloads were moved to more recent levels of subsystem and compiler software. Third, and most significant, the measurement environment for the LSPR now includes both single-image z/OS and multi-image z/OS in separate tables.  

 Question: 

Why are there two tables in the latest LSPR?

 Answer: 

 The LSPR has been enhanced to include performance ratios reflecting both "single-image" z/OS and "multi-image" z/OS environments. Traditionally, the data presented in the LSPR was based on processors configured with one z/OS image equal in size to the processor model (the exception to this was that for z990 models with greater than 16 CPs, two images of z/OS were used). Extensive profiling of client usage of zSeries processors has shown that over 95% of the processors have significantly exploited the virtualization capabilities of the zSeries platform, that is, they are configured with multiple images of z/OS. Thus, the LSPR now includes a table of performance ratios based on average multi-image z/OS configurations for each processor model as determined from the profiling data. Since the multi-image z/OS table is much more representative of the vast majority of client configurations, it is used as the basis for establishing the single-number metrics associated with the z9-109 processor. 

 Question: 

What multi-image configurations are used to produce the LSPR multi-image table?

 Answer: 

 Based on the profiling data, a wide variety of multi-image configurations exist. The main variables in the configuration are: 1) number of images, 2) size of each image (number of logical engines), 3) relative weight of each image, and 4) overall ratio of logical engines to physical engines. The configurations used for the LSPR multi-image table are based on the average values for these variables as observed across a processor family. It was found that the average number of images ranged from 5 at low-end models to 9 at the high end. Most systems were configured with 2 major images (those defined with >10% relative weight). On low- to mid-range models, at least one of the major images tended to be configured with a number of logical engines close to the number of physical engines. On high-end boxes, the major images were generally configured with a number of logical engines well below the count of physical engines reflecting the more common use of these processors for consolidation. The overall ratio of logical to physical engines (often referred to as "the level of overcomittment" in a virtualized environment) averaged as high as 5:1 on the smallest models, hovered around 2:1 across the majority of models, and dropped to 1.5:1 on the largest models. 

 Question: 

Which LSPR table should I use for capacity sizing?

 Answer: 

For high-level sizing, most users will find the multi-image table to reflect configurations closest to their own. This is simply due to the fact that most systems are run with multiple z/OS images. However, the most accurate sizings require the zPCR tool which can be customized to exactly match a specific multi-image configuration rather than the average configurations reflected in the multi-image LSPR table.

 Question: 

If I compare the two tables, why are the capacity ratios for some models higher in the single-image table while other models have higher ratios in the multi-image table?

 Answer: 

Just as capacity ratios are sensitive to workload characteristics (note the varying capacity ratios within a table associated with different workloads), capacity ratios will also be sensitive to the configuration of z/OS images on a processor. If one compares a processor configured only with a single, large z/OS image to the same processor configured with multiple z/OS images, there are both pluses and minuses that come into play. There is a cost incurred to manage multiple z/OS images and their associated logical processors. There is also a cost incurred as the size of a z/OS image increases. Thus, if one compares a configuration of a single large z/OS image to a configuration of multiple but smaller z/OS images, the net result can vary as the magnitude of the pluses and minuses will vary. The sensitivity of the multi-image configurations to the number of images, size of each image, relative weights and overall logical:physical ratio will cause a fair amount of variability in the capacity ratios of these configurations. The multi-image table provides a representative view of these ratios based on average configurations. However, "your mileage will vary" as configurations deviate from average. The zPCR tool can provide capacity ratios customized to specific configurations.

 Question: 

What model is used as the "base" processor in the z/OS V1R6 LSPR tables?

 Answer: 

 The 2084-301 processor running a single copy of z/OS is used as the base in the z/OS V1R6 tables. Thus, the ITRR for the 301 appears as 1.00 in the single-image table. The 301 in the multi-image table was configured with 5 images of z/OS, thus incurruing a cost to run this complex LPAR configuration. Therefore, in the multi-image table, the 301 appears with an ITRR of 0.95 (note that the actual ITRR is 0.954 but the LSPR tables show only two decimal digits).