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
|
Home
| Press
Room | Contact
Us | Site
Map
