isham research

MIPS and MSUs - IBM z990

Please check the note about mainframe investment

Values are given in z990-1.6 Millions of Instructions per Second - zMIPS. These bear no relation to any previous MIPS values given for earlier systems because the z990 LSPR workloadsNote 1 are very different - even the methodology has changed and significant changes have been incorporated in z/OS 1.6. 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 MIPS chart and discussion current at the original z990 announcement can be found here - it has largely been overtaken by events.

IBM has now made LSPR information available for the z990 both using z/OS 1.6 and going up to the 24-way LPAR it now supports. Performance for most systems has been restated and the much criticised linear interpolation used between 16-way and 24-way engines has been eliminated, though it still characterises the charging MSUs that were originally derived from it.

LPAR
Engines

zMIPS

Charging
MSUs

LPAR
Engines

zMIPS

Charging
MSUs

1 450 70 13 4505 661
2 855 132 14 4770 696
3 1251 191 15 5018 730
4 1634 248 16 5261 761
5 2003 302 17 5499 787
6 2363 352 18 5729 813
7 2709 402 19 5949 837
8 3042 448 20 6161 859
9 3362 492 21 6368 880
10 3663 538 22 6561 898
11 3956 580 23 6746 915
12 4235 620 24 6926 930

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 (probably in June) - 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.

Even assuming LSPR is correct, a user operating a 24-engine LPAR on a mixed workload will see 36% of the purchased power eaten up in MP overheads. This could rise to almost 45% with a 32-way LPAR - and on a pure extrapolation seems to start falling off at the 38-way point. A great deal has been done to improve MVS MP efficiency over the years, but it seems that inter-LPAR efficiency is now becoming much more important than intra-LPAR efficiency.

Notes: