MSU and MIPS

[Quasar Chunawala]

Hi all,

MIPS has never been used as a unit to measure mainframe processing power. Instead, they use SU(Service units). A simple equation one could formulate to calculate capacity would be,

Capacity(MSU's) = Duration x SU_SEC(constant published by IBM).

I do not understand, why the SU_SEC constant different for various models of System Z?

Thanks.

[Anuj Dhawan]

On other topic of similar nature I was talking to Robert - adding your question to that leads us into something that appears to cause great confusion and interesting too at the same time – just what are MSU and what do they mean? But that we might continue there too.

OTOH, SU_SEC comes from R723MADJ in the SMF TYPE72 records, and is specific to the system being IPLed and so is constant for that machine but changes as the m/c changes. This is from an online found resource:

The fact that some TYPE72 reporting is in service units raises the question of how time is converted to service units and, how we can convert back from service units to time. Since it seems obvious that the total capacity we have on our machine in any given interval is the duration of that interval times the number of processors we have, CAPACITY=DURATION*ENGINES, how do we convert from service units to time and see how much capacity we actually used in a given amount of time? IBM’s answer is the R723MADJ field, which gives us the service units per second, expressed in Merrill Consultants MXG product as SU_SEC. The term SU_SEC will be used through the rest of this paper to refer to the value of service units per second given to us in the TYPE72 data. The way this value is determined is of extreme interest to us as capacity planners.

The SU_SEC is determined at IPL time and is based on the number of engines online to an LPAR at IPL time. The IBM SRM constants table is in memory. The STSI model number corresponding to the number of engines for the STIDP processor type is determined and that value is reported by the TYPE72s for the life of the IPL. An example is if the processor is a 2094 and there are six engines online at IPL, then the SU_SEC will be the SRM constant for a 2094-706. Before IRD, this was no problem. The number of processors online to an LPAR remained constant unless changed by manual intervention, something rarely done in most shops. After IRD became available, the machine makes changes automatically and no one really knows how many engines are online to an LPAR during a given interval. A good guess can be made by sampling, and RMF does this. But, the amount of actual time consumed by each service or report class cannot be determined any more with true reliability. And keep in mind that when more engines are online the fewer service units any one engine can actually deliver. Conversely, when fewer engines are online, the more service units each one can deliver.

[Robert Sample]

SU_SEC is (available) service units per second. For a single-processor machine, the SU_SEC is easy to understand -- the service units of that processor. However, when you have two processors in a machine (IBM supports different maximums per machine, depending upon the series), you cannot just double the single-processor SU_SEC to arrive at the 2-processor SU_SEC. This is because some of the service units of the 2-processor are required for communication between the 2 processors (you don't want both machines to write to the same page of memory at the same time, so they have to coordinate their work). Hence the SU_SEC of the 2-processor machine will be less than double that of the 1-processor machine. As the number of processors in the box goes up, the amount of communication required increases and hence the SU_SEC is unique for each combination of processors in a series.

MSU is short for Millions of Service Units (since most capacity planning is looking at usage by hour, not by second, multiply SU_SEC times 60 times 60 to derive MSU).

[Quasar Chunawala]

Anuj,

I read the article quoted by you. CPU time can be converted to SUs by multiplying DURATION x SU_SEC(the SU_SEC is processor dependent). SU_SEC differs, because different processors have different clock speeds, so one z12 CPU second is not equal to one z10 CPU second.

MSU capacity of an LPAR would be = SU's x 60 x 60 x ENGINES. To add to it, Robert said, some SU's of the second engine are spent in co-ordination. MXG, Omegamon and several other products can tell you the MSU capacity of you

There are other interesting things I came across like "Technology Dividend". IBM offers a 10% MSU discount, when you upgrade to a newer generation of System Z. If work is done on specialty engines like zIIP and zAAP, MSU capacity is affected.

Robert,

Thanks for the excellent example!

On second thoughts, can we merge the both the topics? I should have searched the forum.

Quasar.

[Anuj Dhawan]

On second thoughts, can we merge the both the topics? I should have searched the forum.

That's fine Quasar, no problem with that. I referred the other topic just in case that gives you better insight.

Have a good one,