isham research
MIPS and MSUs - IBM z990
This page may only be used under the terms of the disclaimer at the foot of the page.

This is the original version of this page, preserved unchanged for the archives. The current version is here

Values are given in z990 Millions of Instructions per Second - zMIPS. These are not comparable with the MIPS values given for earlier systems because the z990 LSPR workloads^{Note 5} are very different - even the methodology has changed. Comparison of an earlier system with a z990 requires consideration of many variables. There are other tables on the Internet. There is no single factor that can be applied to make this conversion.

The column headed "Charging MSUs" reflects IBM's reannouncement of z990 MSUs^{Note 4} for charging purposes in the light of the system's underperformance.

The above is how the MIPS/MSUs table looks according to LSPR as stated to be current on IBM's web site as of 7 April 2004 when z/OS support for 24 processor LPARs was announced. However - analysis of this table and the charging MSU values derived from it gives rise to concern in the light of this announcement.

Drawing a simple graph using a spreadsheet shows that the decline in each successive engine's contribution to system power for configurations between the 2084-303 and 2084-315 is remarkably flat - this is as expected in multiprocessor systems. The area under the line corresponds to total system capacity. At the 2084-316 and above, this effect mysteriously ceases and processors can apparently be added without further multi-processor effect degradation. This curious straight line in overall system performance was immediately commented on by an audience of analysts when the z990 was first announced. Please read the note about 32-way LSPR values. This leads to an interesting situation at the 24-processor point - charging MSUs are stated in LSPR as 1076, rather than the 930 MSUs that the multiprocessor effect would imply.

This is how the table looks if restated using an extrapolation to 24-way of the 1-way to 16-way MP effect shown in LSPR - a shortfall of 146 MSUs and 890 MIPS at the top end.

The deltas between these tables - IBM's original and the restated one above - are immensely important. The key problem lies in the LSPR approach - it was designed for 4-way to 6-way systems and was run in non-LPAR mode until May 2003. It is hopelessly inadequate for representing the performance of n-way systems with a significant number of engines grouped into an unknown number of LPARs as a single number^{Note 6}. Ultimately, there is an underlying assumption in LSPR - and in many software charges - that all machines are configured as single images. But a user can configure a z990 in a massive number of ways - a 16-way can be configured as a single LPAR, 2 x 8-ways, 4 x 4-ways, 8 x 2-ways or any of the combinations in between. With z/OS 1.6, the maximum LPAR size becomes 24 processors, and IBM now has a Statement of Direction to increase this to 32 during 2005 - so the problem will only get worse. This makes a huge difference to the machine's performance - assuming an adaptable workload, some configurations are much more efficient than others. This is because there are major differences between the effects of multiprocessor interference within a domain and the effects of inter-LPAR interference - although the latter has apparently never been rigorously measured.

Sometimes this works to the user's advantage. Assuming z990 underperformance has been compensated (by the use of "charging" MSUs and an acquisition discount) most users will configure their systems into a - probably small - number of separate LPARs for production and thus not suffer the declining contribution caused by MP effects in large single images. They will, of course, see more inter-LPAR interference - and LSPR contains little or no information on predicting this. In some cases it works to the user's detriment, as in the case of the 24-way LPAR in the above table - although perhaps few users will define such LPARs.

Getting an acquisition discount using researched materials is relatively easy - but the "Charging MSUs" column is much more dangerous than the "zMIPS" column - it defines software charge levels and these are much harder to negotiate. Users who believe their z990s are underperforming should not seek acquisition discounts - they should instead seek redefined charging MSU values that should be applied to both the acquisition and future software charges.

IBM's note about 32-way LSPR values is easily missed by a superficial search. It's on page 76 of a manual not directly linked^{Note 7} from the main z990 LSPR page and there's no hint (except here) that it should be read when making what will amount to a multi-million dollar decision. Further, despite the fact that this note is specific to the z990, that term doesn't occur in the text - although it occurs in five other places in the same manual. Given the software charges some installations pay based on the nominal MSU values derived from LSPR, one might perhaps have expected a less arbitrary methodology - one wonders how a 54-way would be handled:

"For a 32 way MP, two 16 way images of z/OS are measured and the ITR reflects the sum of the workload rates of each. Thus, an ITR is established in an environment where the z/OS effects are similar to that measured at the 16 way MP configuration, that is, both configurations involve 16 way images of z/OS (one such image on the 16 way MP, and two such images on the 32 way MP). Then, to preserve this "equal software effects" philosophy, the ratings for the 17 way through 31 way MP are established by a linear interpolation between the 16 way and 32 way points. It is felt that this provides the most representative and "middle-of-the-road" rating for MP configurations that require multiple OS images (in lieu of having to account for varying OS effects which would result from changing the z/OS n-way image size for each processor MP configuration)."

SC28-1187-09 Large Systems Performance Reference Page 76

Disclaimer:
In common with other analysts, isham research performs no benchmarks and has never operated any of these machines. All values are based entirely on the same quality of intelligence that "justified" the attack on Iraq and were tabulated on the clumsiest of equipment^{Note 10} in the harshest of environments^{Note 9} and under the influence of chemicals^{Note 8}. Those who quote system performance to four figure precision without knowing even the operating system - much less the workload mix and LPAR configuration - are dangers to themselves and others. Errors and omissions excepted. Your mileage WILL vary. Do not refreeze once thawed. Void where prohibited. May contain traces of nuts. Open only in a well-ventilated place. Parental guidance recommended. Caveat emptor. Alle Angaben ohne Gewähr. It's worth what you paid for it.

Notes:

• Note 1 - See APAR OW50998 against IRASRCPC.
• Note 2 - These values have been restated using the MP factors of the original 16-way measurement.
• Note 3 - One wonders sometimes whether IBM does, either. Rumours have even suggested that only uniprocessor, 3-way and 16-way systems were measured. It seems implausible that all workloads are run on all configurations, but IBM does not distinguish between actual measurements and extrapolations in its presentation of LSPR data - if indeed there are any measurements of full configurations:

  "As capacities of today's processors grow ever larger, it becomes more difficult to commit the time, and/or the external resources necessary for full, unconstrained LSPR measurements. Experience has shown that there are estimation techniques, based on making reduced resource measurements and analysis, that can yield reliable results."
  
  SC28-1187-09 Large Systems Performance Reference (ob cit) Page 52

• Note 4 - effective 1 October 2003, a reduction in MSU values of around 10%. Because of the degressive nature of MSU-based charges, this made a negligible difference to software charges. It is possibly explained by new industry-wide stringency about revenue recognition. IBM has set exemplary standards in the past, but the text of 1975's SFAS 5 is now being more rigorously interpreted by the whole industry. An MSU value that is said to be directly related to system performance may constitute a "performance guarantee" and thus a "contingent liability" that might prevent early recognition of the revenue. IBM's new terminology specifically states that z990 MSUs are not performance statements:

  "MSUs are used for software pricing and are not necessarily a direct indication of relative processor capacity."
  
  SC28-1187-09 Large Systems Performance Reference (ob cit) Page 78

• Note 5 - the most concise description of the LSPR workload changes for the z990 is in SG24-6947-01 - z990 Technical Description, Page 224. SC28-1187-09 Large Systems Performance Reference (ob cit) page 40ff also lists a number of discontinued workloads such as CICS/DB2, CICS, DB2 and FPC1. The fact that these are no longer factored in to the "mix" adds to the unsuitability of single numbers such as MIPS for comparing older and newer systems.
• Note 6 - LSPR also addresses z890 and z990 performance as if the only criterion were the performance of the processors characterised for z/OS use - it ignores the contributions of CFs, IFLs, zAAPs and SAPs all of which can serve to increase the throughput of the system in a way invisible to LSPR. The z990 LSPR "mix" workload even includes a 20% WebSphere factor - a prime candidate for a zAAP. This can be particularly misleading with the z890 where "kneecapped" z/OS processors are used in combination with full power zAAPS. And, of course, LSPR is notably deficient in its lack of a direct price/performance metric - all other standard benchmarks contain a cost component. The presentation of zSeries performance needs a major overhaul.
• Note 7 - After this page was published IBM added a line to the z990's LSPR tables between the 16-way and 17-way values indicating that the 17-way and above figures are based on multiple domains, i.e., there was then no 24-way LPAR measurement data available. It was expected towards the end of August 2004, but finally arrived in October.
• Note 8 - Ind Coope "Burton Ale", Timothy Taylor's "Landlord" and Tetley Handpull.
• Note 9 - The White Lion, Heeley Bottom, Sheffield during a gig by the loud but tuneful "Sour Mash". Subsequent analysis in the Woodseats to the noise of "Fade 2 Black".
• Note 10 - an HP41-CV and Microsoft Excel on a ThinkPad TransNote.

Copyright © isham research 2006

isham research Home Page

MIPS Index