MIPS stands for “millions of instructions per second” and is the primary way mainframe capacity is measured and discussed. Despite the name, MIPS in the mainframe world doesn’t literally count how many instructions a processor executes each second. Instead, it’s a relative capacity rating derived from benchmark tables published by IBM, used to size workloads, plan upgrades, and determine software licensing costs.
What MIPS Actually Measures
The acronym suggests a straightforward metric: how many millions of instructions a processor can churn through every second. In practice, mainframe MIPS values come from IBM’s Large Systems Performance Reference (LSPR) tables, which assign relative capacity ratios to each processor model based on standardized benchmark workloads. A given mainframe model’s MIPS rating represents its capacity compared to a baseline reference system, not a raw instruction count.
IBM describes these ratios as representing “relative processor capacity in an unconstrained environment for specific benchmark workloads.” The key word is “relative.” A machine rated at 10,000 MIPS has roughly ten times the processing capacity of a machine rated at 1,000 MIPS, but neither number reflects the actual number of instructions being executed. This distinction matters because different types of work (batch processing, database queries, transaction handling) stress the processor in different ways, and a single instruction count wouldn’t capture those differences.
The gap between the name and the reality led engineers as far back as the 1980s to joke that MIPS really stood for “Meaningless Indicator of Processor Speed.” The criticism is valid when comparing completely different processor architectures, but within the IBM Z ecosystem, MIPS remains a practical and widely understood unit for comparing capacity across hardware generations.
How MIPS Ratings Are Assigned
IBM publishes LSPR tables that rate every mainframe processor model against a common baseline: the IBM System z9 model 2094-701, which is set to 1.00. Each processor model gets multiple ratings depending on workload intensity. For example, a single-processor IBM z16 model 3931-701 scores about 1.67 on an average workload, meaning it has roughly 67% more capacity than the old baseline system. A fully loaded z16 with 100 processors (model 3931-7A0) scores around 221 on the same average workload, representing over 200 times the baseline capacity.
The LSPR tables also break ratings into “low,” “average,” and “high” categories based on something called Relative Nest Intensity, which reflects how heavily a workload uses the processor’s memory subsystem. A workload that constantly fetches data from memory (high intensity) will get less throughput from the same hardware than one that mostly works with data already in the processor’s cache (low intensity). This is why a z16 with 100 processors scores 266 for low-intensity work but only 196 for high-intensity work on the same hardware.
IBM notes that real-world performance can vary from LSPR ratios due to differences in your actual workload characteristics, your operating system configuration, and any I/O bottlenecks in your environment. The ratings assume an unconstrained system with no storage or network limitations.
MIPS vs. MSU: Two Sides of the Same Coin
You’ll often see MIPS mentioned alongside MSU, or “million service units.” While MIPS represents raw processing capacity, MSU measures the amount of processing work a system can perform in one hour and is specifically used for IBM software pricing. IBM explicitly states that MSUs “are used for software pricing only; they are not a capacity metric.”
The distinction matters because IBM licenses much of its mainframe software based on how much MSU capacity your system consumes. This is called Monthly License Charge (MLC) pricing. IBM even provides a Sub-capacity Reporting Tool (SCRT) that tracks how much processor time your licensed software actually uses, so you can pay based on consumption rather than total installed capacity. The relationship between MIPS and MSU isn’t a simple conversion factor. It varies by processor model and generation, which is why both metrics persist in parallel.
Why MIPS Drives Mainframe Costs
MIPS is more than a technical benchmark. It’s the unit that determines a significant portion of your mainframe budget. Software licensing fees, hardware upgrade decisions, and capacity planning all revolve around how many MIPS your environment needs.
Estimates for the cost of a single MIPS vary wildly depending on who’s counting and what they include. A 2015 academic paper in the journal Science of Computer Programming put the average cost at $3,285 per MIPS, with an expected 20% annual increase, which would put the figure somewhere around $20,000 per MIPS by 2025. An AWS blog post offered a very different number: roughly $1,600 per installed MIPS annually for a large mainframe over 11,000 MIPS, with hardware and software accounting for about 65% of that cost ($1,040). The enormous spread between these estimates reflects differences in what’s being counted (hardware only vs. total cost of ownership including staff, facilities, and support) and the size of the installation. Larger shops generally pay less per MIPS because costs spread across more capacity.
This cost sensitivity is exactly why organizations obsess over MIPS efficiency. Reducing MIPS consumption by optimizing application code, tuning database queries, or offloading work to specialty processors can translate directly into lower software bills.
How Mainframe Teams Monitor MIPS Usage
Capacity planning teams track MIPS consumption at multiple levels to keep costs under control and avoid performance problems. IBM’s tools let you monitor utilization across the entire central electronics complex (CEC), individual logical partitions (LPARs), specific workloads, and even individual business applications.
At the broadest level, an hourly MIPS usage report for the whole system can reveal specific times of day when the machine approaches saturation because heavy workloads overlap across multiple partitions. Peak utilization reports identify predictable busy periods like end-of-month processing or seasonal spikes, giving teams the chance to reschedule batch jobs, rebalance partition weights, or activate on-demand capacity before performance degrades.
At a more granular level, tracking MIPS by workload type helps pinpoint which applications or services are consuming the most capacity. If a single batch job is burning through an outsized share of MIPS, that’s a candidate for code optimization or rescheduling to off-peak hours. This kind of analysis is where MIPS becomes a practical management tool rather than an abstract number, connecting processor utilization directly to business decisions about when to run work, how to allocate resources, and when it’s time to upgrade hardware.