isham research
Values are given in System z9 kilo-Millions of Instructions per Second. These bear no relation to any previous MIPS values given for earlier systems because the z9 LSPR workloads are very different - the workloads have been changed to suit the machine yet again. The mix is even more striking - it's 30% online transaction processing and 70% other, moving in the opposite direction to most users' workloads and making LSPR even less relevant than before. It's obvious from the graph why this was done - the CB-L workload significantly lifts the LSPR Mix figure on which software charges are ultimately based.
Comparison of a System z9 with an earlier system requires consideration of many variables. There are other tables on the Internet, including IBM's own. There is no single factor that can be applied to make this conversion.
These tables only go to 20 processors within an LPAR. The data beyond this point is even less reliable than the rest. With the introduction and exploitation of Advanced Availability (Concurrent Book Removal) the physical 54-way configured with 40 characterisable processors becomes the definitive very top end machine - but z/OS 1.7 only supports up to 32 processors in an image so multiple LPARs are unavoidable. Two 20-way LPARs is only one of the options.
The MSUs in this table are final software charging MSUs. The z9 shows a mean of 7.62 LSPR Mix MIPS/MSU, almost exactly a 10% increase on the z990's 6.93 - but this will not produce anything like a 10% reduction in software charges because the upper ranges of MSU-based prices are on a much more gradual slope.
| LPAR Engines |
z9 kMIPS | MSUs | LPAR Engines |
z9 kMIPS | MSUs |
|---|---|---|---|---|---|
| 1 | 0.6 | 81 | 11 | 5.3 | 690 |
| 2 | 1.2 | 158 | 12 | 5.7 | 742 |
| 3 | 1.7 | 229 | 13 | 6.1 | 795 |
| 4 | 2.3 | 298 | 14 | 6.5 | 843 |
| 5 | 2.8 | 363 | 15 | 6.9 | 893 |
| 6 | 3.2 | 422 | 16 | 7.2 | 938 |
| 7 | 3.7 | 479 | 17 | 7.6 | 985 |
| 8 | 4.1 | 532 | 18 | 8.0 | 1032 |
| 9 | 4.6 | 584 | 19 | 8.3 | 1077 |
| 10 | 4.9 | 640 | 20 | 8.6 | 1127 |
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 z9 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 the System z9, up to 54 processors might be available with z/OS 1.7 supporting up to 32 in a single LPAR - so the problem will only get worse. This may make 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.
Even assuming LSPR is correct, a user operating a 32-engine LPAR will see perhaps 45% of the purchased power eaten up in MP overheads. 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.
With the z990, rumours 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 Page 52
What does that mean for the System z9 - headlined at 18,660 MIPS versus the z990's 9,542? Looking at the published MIPS figures (graphing them is better) there are some odd features:
| Upgrade | MIPS added | Delta to previous upgrade |
|---|---|---|
| 1 --> 2 | 579 | |
| 2 --> 3 | 551 | 28 |
| 3 --> 4 | 524 | 27 |
| 4 --> 5 | 499 | 25 |
| 5 --> 6 | 474 | 24 |
| 6 --> 7 | 451 | 23 |
| 7 --> 8 | 429 | 22 |
| 8 --> 9 | 421 | 9 |
| 9 --> 10 | 412 | 9 |
| 10 --> 11 | 403 | 8 |
| 11 --> 12 | 395 | 8 |
| 12 --> 13 | 387 | 8 |
| 13 --> 14 | 379 | 8 |
| 14 --> 15 | 371 | 8 |
| 15 --> 16 | 364 | 8 |
| 16 --> 17 | 356 | 7 |
| 17 --> 18 | 349 | 7 |
| 18 --> 19 | 346 | 3 |
| 19 --> 20 | 343 | 3 |
| 20 --> 21 | 340 | 3 |
| 21 --> 22 | 337 | 3 |
| 22 --> 23 | 335 | 3 |
| 23 --> 24 | 332 | 3 |
| 24 --> 25 | 329 | 3 |
| 25 --> 26 | 327 | 3 |
| 26 --> 27 | 324 | 3 |
| 27 --> 28 | 321 | 3 |
| 28 --> 29 | 319 | 2 |
| 29 --> 30 | 317 | 2 |
| 30 --> 31 | 316 | 2 |
| 31 --> 32 | 314 | 2 |
| 32 --> 33 | 312 | 2 |
| 33 --> 34 | 310 | 2 |
| 34 --> 35 | 308 | 2 |
| 35 --> 36 | 306 | 2 |
| 36 --> 37 | 304 | 2 |
| 37 --> 38 | 302 | 2 |
| 38 --> 39 | 298 | 5 |
| 39 --> 40 | 293 | 4 |
| 40 --> 41 | 289 | 4 |
| 41 --> 42 | 285 | 4 |
| 42 --> 43 | 280 | 4 |
| 43 --> 44 | 276 | 4 |
| 44 --> 45 | 272 | 4 |
| 45 --> 46 | 268 | 4 |
| 46 --> 47 | 264 | 4 |
| 47 --> 48 | 260 | 4 |
| 48 --> 49 | 256 | 4 |
| 49 --> 50 | 252 | 4 |
| 50 --> 51 | 248 | 4 |
| 51 --> 52 | 245 | 4 |
| 52 --> 53 | 241 | 4 |
| 53 --> 54 | 237 | 4 |
These are very strange numbers indeed. Some oddness is to be expected with the larger systems, since they are built with a different MCM - all chip slots being occupied by twin-stack chips against the smaller systems' use of an MCM with four singles and four twins. The discontinuity with the ninth processor is odd, as is the appearance of four very straight lines. When IBM used PCM vendor claims in LSPR tables, it used to differentiate them from measurements:
LSPR tables differentiate ITRs based on vendor-claims from measured ITRs with the designation "v".
SC28-1187-10 Large Systems Performance Reference Page 53
IBM has decided to make its zPCR 3.0 tool available to users, who will then be able to generate their own rubbish - but to eight decimal places.
Notes:
Copyright © isham research 2006, 2008