6. DATA SOURCES › 6.4 CPU Time Measurements › 6.4.5 CPU Service Units

6.4.5 CPU Service Units

Installation management has three major concerns when
migrating from one computer system to another:

  o  Will the new system produce output that is as correct as
     the previous system's?

  o  How much application growth will the new system support?

  o  What accounting algorithm will yield charges that are
     consistent with current charges for equivalent
     workloads?

The Service Unit (SU) concept is an attempt to answer the
second and third questions by putting utilization of CPU
resources on a processor-independent basis.  It assumes that
a benchmark application will require some constant quantity
of some CPU resource (which we leave undefined but call an
SU), no matter what system it runs on.  Faster systems will
require less CPU time to produce the same number of SUs.  One
system is selected as a standard and arbitrarily assigned
some number of SUs per CPU second.  If a test system runs the
benchmark twice as fast as the standard, the test system is
rated at twice as many SUs per CPU second.

Given a consistent set of SU ratings for a series of systems,
management can address concerns two and three.  If the new
system is rated at, for instance, 140% more SUs per CPU
second than the old one, then the installation can expect to
be able to support 140% growth in its workload.  If charges
are based on SUs rather than CPU seconds, then user charges
will not show drastic variation as the installation migrates
between systems.

But is there a consistent set of SU ratings? A set of
benchmarks has been developed to represent a variety of
"typical" types of machine utilization (batch commercial,
online commercial, online scientific, etc.), but each leads
to more or less different sets of SU ratings for a given set
of systems.  Even with a single benchmark, each system's SU
rating is sensitive to changes in the hardware and software
maintenance levels, as well as all the sources of variability
listed above.

Nevertheless, some sort of number is necessary for at least
rudimentary system management.  To meet that demand, a set of
"SUs per CPU second" numbers has been published.  There is no
claim that these "SRM constants" are accurate indices of
relative computer "power" in any specific environment.
However, they have proven fairly accurate and adequate for
many capacity and chargeback purposes.

SRM exploits SU's approximate system-independence in its CPU-
management algorithms.  To the extent that systems are well
balanced (CPU "power" versus channel capacity versus real
storage size), tuning policies expressed in terms of SUs will
retain their usefulness as the installation migrates to
larger MVS systems.  For example, the Interval Service Value
(ISV) is the minimum amount of service an address space can
expect to receive before its next involuntary swap-out.  The
active IEAIPSxx member contains an ISV specification for each
performance period.  If the ISV were expressed in terms of
CPU seconds, then the installation would have to revise its
selection of ISV values for each new system.  Because the ISV
is expressed in terms of SUs, one set of ISV values suffices
to represent installation policy for any machine.

The CA MICS data base includes several data elements based on
the SU concept.  PGMTCBSU, for instance, is intended for use
as an approximately system-independent measure of TCB-level
CPU utilization.  The values of PGMTCBSU and PGMTCBTM are
related by

  PGMTCBSU=PGMTCBTM * (IPS TCB coefficient) * (SRM constant)

Within the variability discussed in Section 6.4.4, replicate
runs of an application on the same or different systems
should show about the same values of PGMTCBSU even if the
PGMTCBTM values are far apart.  If capacity calculations are
scaled to projected PGMTCBSU growth rates, then they should
transfer well to other systems.  If user budgets are prepared
in terms of PGMTCBSU projections and chargeback is calculated
in the same units, then the accounting figures should require
only minor revisions at system migration time.

One additional note.  The above discussion ignores a general
phenomenon, called "latent demand," that is often a source of
surprise to installations that go from a machine-constrained
situation to one with excess system capacity.  Latent demand
is a sudden increase of utilization that occurs because users
respond to reduced turnaround times by submitting additional
work that before had simply taken too long to complete.