MIPS versus MSUs: What’s the Difference?

How do we rate the capacity of IBM System Z mainframe hardware? Well, these days, IBM publishes the capacity rating of every mainframe that they sell in MSUs, not MIPS. But let’s not get ahead of ourselves.

When people discuss mainframe capacity, they often talk in terms of MIPS. But what does MIPS mean? And what is an MSU?

A Little Bit of MIPS History

Starting at the beginning, the question to ask is, “What is MIPS?” Or should it be “What are MIPS?” Well, MIPS is actually an acronym, and it stands for Millions of Instructions Per Second. So there really is no such thing as a MIP because MIPS is not plural. As the name implies, MIPS stands for the number of instructions that a particular mainframe can process using a second of operating time.

Historically, mainframe computers were measured in terms of MIPS, that is, the number of instructions that could be processed per second. MIPS was used as a way to measure the general computing capacity of a mainframe. Of course, other large servers can be measured using MIPS, too, but we will focus on mainframes here.

Benchmark runs are usually conducted to attribute a capacity in MIPS to a particular computer. The larger the number of MIPS assigned to a computer, the larger the workload it can process. Over time, MIPS no longer translated to an actual millions of instructions per second that a computer could process.

Why is that so? Well, there are differences in the ways that different models of IBM System Z mainframes work, making it difficult to translate capacity in MIPS from model to model. Furthermore, different types of workload and settings can impact how MIPS are measured. Things like the amount and efficiency of memory available, the speed of I/O devices, and the mixture and complexity of the workloads being run all conspired to make MIPS mean something different.

These days, MIPS are a somewhat obsolete way of comparing the CPU capacity across different mainframe models and hardware configurations. Instead, we talk about MSUs.

What About MSUs Then?

Instead of MIPS, most capacity planners measure mainframe capacity using MSUs, which is a more modern measurement. As mentioned at the top of the article, IBM publishes the capacity rating of every mainframe it sells in terms of MSUs.

What is an MSU? MSU is also an acronym, and it stands for Million Service Units. And that begs the question, “what is a service unit?” One “service unit” originally related to an actual hardware performance measurement, but that is no longer the case. A service unit is an imprecise measurement, and it is determined by IBM as a means to rate the capacity of their mainframe computers.

Instantaneous MSU, or IMSU, is a measurement of the number of MSUs used at a given time.  IMSU usage is used to determine your monthly IBM software bill when using a sub-capacity pricing metric. The peak rolling four-hour average (R4HA) of instantaneous MSU usage for the month determines the usage for billing purposes (elaborated upon in this article). This information is recorded in SMF Type 70 and 89 records that capture CPU activity and product usage information.

Sometimes people conflate MSU usage with performance, but the two are different.

Additionally, keep in mind that, at times, IBM has reduced the number of MSUs for a given workload as you move to newer and more modern hardware. This is referred to as the technology dividend. So, running the same workload on a newer machine may be less costly than running it on an older machine. This may be an historic artifact, though, as IBM has stopped giving the technology dividend with recent IBM Z hardware releases. It may be relevant to some shops using older hardware, though.

Can We Convert MIPS to MSUs… and Vice Versa?

Sometimes people like the comfort of using terms they have used for years. As such, MIPS is still used by many IBM mainframe shops to discuss the capacity of their systems. Additionally, outsourcers frequently use MIPS in their contracts and service-level agreements. So, a method of converting back and forth between MIPS and MSUs is a common requirement.

Such a conversion is somewhat imprecise, but industry analysts at Longpela indicate that 1 MSU equates to somewhere between 8 to 9 MIPS. So, you can plug in 8.5 as a conversion factor. For example, how many MIPS are in 150 MSUs?

          150 MSUs * 8.5 = 1,200 MIPS

What Do You Measure?

Now that we understand MSUs and MIPS and the difference between them, what metrics should you use, and when should you use them? Of course, the answer depends on what you are trying to achieve.

For the purpose of cost containment of your IBM software bill, the answer is that you should measure MSUs. The exact type of MSU measurements you will need to review depends on the kind of pricing model you have in place with IBM for your mainframe. If you are under a sub-capacity plan, then you should review the rolling four-hour average (R4HA) MSUs. We have discussed the R4HA in past articles, but the general idea is that your monthly IBM MLC software bill is based on the peak 4-hour average of MSU usage per LPAR per product.

Make sure to distinguish the R4HA from instantaneous MSU (IMSU) consumption. The IMSU consumption at any point in time shows the MSU capacity being used for an LPAR. The R4HA is the average value of the last 4 hours of IMSU consumption.

And yes, it is important to understand that IMSU and MSU consumption are only tracked at the LPAR level. It is also important to understand that MSUs are not measured for zIIPs. This is so because the zIIP workload is not chargeable, and therefore MSUs are not relevant.

What about for performance management? Performance tuning and cost optimization are two different subjects that have some crossover but require other metrics. Performance is generally measured in terms of CPU seconds or perhaps even elapsed time. Performance management aims to make processes more efficient and, hopefully, to get them to complete faster.

If the goal is to optimize processes, so they run more quickly, then elapsed time (that is the actual time it takes for a process to run) is an interesting metric. But there are many aspects contributing to elapsed time. One aspect that impacts elapsed time is the amount of computing time or CPU seconds required to complete a task. And as the number of CPU seconds required to complete a task goes up, the unused capacity of the mainframe goes down, meaning that you may need to upgrade to a larger capacity machine if you do not tune your workloads.

The operating system measures CPU usage. And CPU seconds can be tracked by LPAR, address space, job, or process. Performance data is collected into SMF records, but you may also have performance measurements collected into other areas using performance monitors and other tools. So, unlike IMSU, CPU usage can be tracked for both general CPs and zIIPs. And why not? We want the processes that run on both to be efficient, so performance tracking and optimization make sense for both traditional CPU and zIIP usage.

Reducing CPU usage should decrease instantaneous MSU consumption. Whether it impacts billing or not depends on whether the CPU reduction happens during a peak R4HA period (see Whack-a-Mole).

So, is it possible to use CPU seconds to compute MSUs? Well, sort of. Analysts at Watson Walker have developed a table converting a given number of CPU seconds into MIPS. IBM and some outsourcing companies may have similar conversion charts. And then, once you get MIPS, you can use the 8.5 MIPS per MSU conversion we discussed earlier to convert to MSUs.

This should give you at least a rough capability for doing such conversions. However, before you do it, think about what you are trying to accomplish and how such a conversion will be used. Remember, measuring and analyzing MSUs and CPU seconds generally are useful for different things