www.longpelaexpertise.com.au/ezine/HowBigMainframe.php?ezinemode=printfriend

LongEx Mainframe Quarterly - March 2011

management: Exactly How Big is Your Mainframe?

The size of your mainframe, LPAR, or z/VM image, is important. It directly affects the cost of your software. It is essential for capacity and disaster recovery planning. And it often determines the cost of an outsourced mainframe. But finding this out is not as easy as you'd think. So how can you find out how big your mainframe really is?

It sounds like an easy question doesn't it? How big is your mainframe? This simple question is important for many things from basic capacity planning to software licensing costs. However finding this out isn't as easy as you'd think. And to make matters worse, the measuring unit you use, be it MIPS, MSU or ITR, can be filled with traps for the unwary. So exactly how do you determine the size of your mainframe?

Method One: MIPS

MIPS, or Millions of Instructions per Second, is probably the most common unit used when talking about mainframe capacity. When mainframes were still young, manufacturers could measure the MIPS capacity by running a small standard routine over and over again.

However MIPS has not been a meaningful measurement for decades. IBM mainframes have a huge number of instructions: some are simple and quick, others complicated and slow. One application using five million simple instructions will use a lot less CPU than one using five million complicated ones. And the number of instructions available is increasing: the z196 has 100 new ones.

Today's processors also use a large range of tricks to improve performance which blurs the very meaning of the term instruction. These range from caching instructions and data to converting complex instructions into more simple ones in microcode. What's more, an increasing amount of processing power is being used for housekeeping tasks such as managing multiprocessor systems and LPAR management. So MIPS is no longer connected to anything real.

Consultants and analysts such as Gartner and IDC publish a list of MIPS ratings for each mainframe model. However these values are not from independent measurements, but are calculated from IBMs published values.

IBM doesn't publish MIPS ratings as such. However it does publish a Processor Capacity Index (PCI) in its Large Systems Performance Reference (LSPR) which is basically the same.

The risk with using published MIPS values is that they aren't the same. For example, the capacity for an IBM 2064-1C5 varies from 1029 (Watson Walker) and 1085 (Hascon) to 1014 (IBM). This difference comes from the fact that MIPS values are calculated from the capacity difference between the processor and a base processor model with a defined MIPS value. For example, IBM uses the 2094-701 as a base machine, and assumes its capacity is 560 MIPS. The z196 2817-502 has been measured to be around twice as big, so its MIPS value will be 2 * 560, or 1200. Different publishers use different base processor models and values.

Even using values from one publisher at different times is fraught with danger. IBM changed the base MIPS value of the 2094-701 from 568 in October 2008 to 560 in May 2010. This means that MIPS ratings for all its machines similarly changed.

So MIPS are fine if you're looking for a very rough guide, but can vary a lot depending on the source and the time the value is obtained.

Method Two: MSU

Traditionally CPU seconds, or the number of seconds a CPU is actually in use, was a measurement of how much work a processor performed. CPU seconds was, and often still is, used as a measurement for charging mainframe usage. z/OS records the number of CPU seconds that each unit of work has consumed, providing an excellent way of measuring the workload. The problem is that the amount of work that can be done in one CPU second is not the same for each processor model. So one z800 CPU second is different to a z196 CPU second.

Service Units were developed to be a number that can be compared across processors. They are calculated by multiplying CPU seconds by a constant value, called an SRM (Systems Resource Manager) constant. IBM publishes SRM constants for each of its processors; and you may think that this could be used as a measure. But the SRM constant has nothing to do with processor size. The z196 2817-415 has the same SRM constant as the 2817-401, but is around 12 times the capacity.

It's from Service Units that MSU was created: Millions of Service Units per Hour. MSU measures the rate of CPU usage, but also can refer to the size of a processor. So a processor with a MSU of 100 can process up to 100 million service units per hour.

Anyone who wants the capacity of a single LPAR or z/VM image rather than the whole processor complex will like MSU. Unlike MIPS, it is possible to obtain the MSU rating for any LPAR or z/VM image. In fact, when systems programmers limit the capacity of an image, they specify an MSU value. Even better, application programs can access this MSU rating. Example REXX and C programs can be found in the Longpela Expertise Tools and Resources section.

MSU is primarily intended for software licensing. Most vendors scale their software licensing fee to an MSU rating. IBMs sub-capacity licensing also uses MSU when calculating the final bill. This makes MSU a tempting number to use for everything, however the very fact that IBM uses it for software licensing is its downfall.

IBM has felt free to tweak the MSU capacity of processors in order to lure users to a newer machine. Recent processor generations have offered a 10% MSU 'discount' on previous models. Or in other words, an application using 100 MSU on a previous processor would only use 90 on the newer model. IBM has offered no MSU discount for the z196.

So it is no surprise that IBM recommends against using MSU for serious capacity planning. But MSU discounting is not the only reason. IBM has found that MSU, as well as MIPS values, can change depending on the workload. So a batch workload will have a different MIPS or MSU to an online workload. In fact IBM has found that this difference is larger with more recent processor models. For example, the difference can be up to 8% for a zSeries 800, and an incredible 34% for the latest z196.

IBM recommends another way of determining capacity.

Method Three: ITRR

IBMs preferred method is to use the Internal Transaction Rate Ratio (ITRR) published in its LSPR. This is a number that compares a processor to IBMs base 2094-701 processor, which has an ITRR of 1.0. The z196 2817-412 has an average ITRR of 4.28, so it is 4.28 times the size of the 2097-701.

The ITRR is measured by IBM for a variety of different workloads such as batch, online transaction and web. The idea is that users calculating their mainframe's capacity match their workload to the closest equivalent workload in the LSPR, and use that value. IBM uses the average ITRR for calculating MIPS values.

This ITRR still isn't perfect. With large differences from workload mixes in the latest processors, there can still be a very big difference between your processor's workload and the ITRR workload. To get around this problem, IBM has created a PC-based tool to calculate a system's ITRR value from RMF and other data. This tool, called the zPCR (System z Processor Capacity Reference), is by far the best way to calculate a system's capacity. It can be downloaded free from the IBM website.

Conclusion

In a nutshell, use ITRR for serious capacity planning, MIPS if you want a nice easy number, and MSUs if you're working with software licensing. All these numbers can be found from IBMs LSPR website, and other publishers such as Hascon, Watson-Walker, Gartner and IDG. However if you need accurate numbers, you need to calculate the capacity using IBMs zPCR tool.

References


David Stephens