Converting CPU Time to MIPS

[Ramiro Camposagrado]

Management is trying to cut and save CPU cost. So they came up with
this "Cost Avoidance Committee". (Primarily consisting of uper management).
Now they want us to somehow equate the CPU Time consumed (primarily by a
CICS transaction) and equate that into MIPS. I know that folks have come up
with formulas on how to do this.

We use BEST/1 (Visualizer) for our performance reporting and it works off 15
minute intervals. Within this 15 minute interval, we can run hundreds of CICS
transactions. If we take one CICS transaction and convert the CPU time used
into MIPS, it is much higher than the 15 minute interval that is being reported
in BEST/1. So there is really no way for us to correlate this number with our
BEST/1 data.

The performance data comes from MXG and it gets fed into BEST/1.
As far as I know, MXG does not report on MIP utilization per CICS transaction.
It does report on the elapsed time and CPU time for individual CPU transactions.
And it would be just to much of an effort for us to report on "MIPS used" for
hundreds of CICS transactions.

Any suggestions or comments ??

Regards,
Ramiro

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to list...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

[Jeffrey Deaver]

> "Cost Avoidance Committee"

What is the ultimate goal of the committee? Are you attempting to stave
off a CPU upgrade? Are you looking to actually decrease the size of your
current configuration? You're most likely locked into a lease or own your
mainframe, so you've already "sunk" the money for the CPU cycles available
- how is examining how those cycles are being used going to avoid cost? Do
you do sub capacity charge on the z/OS software? Or is this an internal
chargeback thing?

Jeffrey Deaver, Engineer
Systems Engineering
jeffrey...@securian.com
651-665-4231(v)
IS - "Creating competitive advantage with technology. Providing service
that excels."
OSS - " Where Innovation Happens"

[Ramiro Camposagrado]

I am quite aware that we have already "sunk" the money for the CPU cycles.
We are paying for "the CPU" wether it is running at 25% percent or 100%.

Management wants to be able to see that, if they made an "application
change" to improve the performance of a particular program, that they will be
quantify the amount of MIPS saved as a reult of the application change.
We actually have a "MIPS reduction committee" that meets on a regular basis
to discuss on how to improve the performance of our most CPU intensive
applications.

Regards,
Ramiro

[Tom Marchant]

On Thu, 2 Jul 2009 10:25:31 -0500, Ramiro Camposagrado wrote:

>Management is trying to cut and save CPU cost. So they came up with
>this "Cost Avoidance Committee". (Primarily consisting of uper management).
>Now they want us to somehow equate the CPU Time consumed (primarily by a
>CICS transaction) and equate that into MIPS. I know that folks have come up
>with formulas on how to do this.

Let's see.... Your Ferrari is capable of going 200 MPH. It took five
minutes to drive to the grocery store one mile away. How many MPH did it use?

You could try to educate your committee. Rather than using convoluted
formulas to come up with meaningless comparisons, you could give them real
data that might give them what they need.

For example. Your processor has (let's say) four engines, each of which can
execute code for 24*60*60 seconds every day. The number of CPU seconds used
by the CICS transaction(s) is what percentage of the available CPU seconds?

You might want to use total reported CPU seconds per day rather than the
theoretical maximum because of system overhead.

--
Tom Marchant

[McKown, John]

I agree that this is meaningless. However, there are two times available to you in a CICS transaction. The CPU used and the elapsed time. Now, if you divide the CPU used by the elapsed, you will get a measure of "how hard" this particular transaction can drive the machine. IMO, any transaction that can drive the machine over 50% is likely either coded poorly or is doing some sort of "heavy computation" on its data. As an example, back a few years ago, before it was possible to use the STRING and UNSTRING verbs in COBOL in CICS and also before COBOL had "reference modification", we had a transaction which had to split its input into blank delimited "words". This transaction was a CPU burner do to "out of line" PERFORMs which had to use arrays to inspect each character.

--
John McKown
Systems Engineer IV
IT

Administrative Services Group

HealthMarkets(r)

9151 Boulevard 26 * N. Richland Hills * TX 76010
(817) 255-3225 phone * (817)-961-6183 cell
john....@healthmarkets.com * www.HealthMarkets.com

Confidentiality Notice: This e-mail message may contain confidential or proprietary information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. HealthMarkets(r) is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance Company(r), Mid-West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM

[Hal Merritt]

They don't really want to know MIPS. They want to know money. That is, how much does it cost to run transaction x.

Perhaps expressing the CPU consumption as a percentage of the box's capacity would answer the question. Each engine has a fixed capacity of one CPU second per clock second, but the MIPS will vary depending on the speed of the engine (among other things). If, for example, you run a four engine, 100 MIP box, then one CPU second = 25% of the box or 25 MIPS. Another example is a four engine 1000 MIP box, then one CPU second is still 25% of the box or 250 MIPS.

Another way to express the capacity of a box is the theoretical maximum number of CPU seconds you can use. Again assuming that you have a four engine box, then the maximum number you can use is 345,600. (24 hours x 60 min x 60 sec x 4). If this is a 100 MIP box, then each MIP is theoretically 34,560 CPU seconds.

You should be able to see the problems that arise trying to express CPU seconds in MIPS.

It get worse. We also have to consider the time value of that transaction. It may take more than one MIP to run 34,500 one second transactions with an acceptable response time.

You should be able to see the problems that arise trying to express CPU seconds in MIPS.

Remember what we are trying to do and who is asking. I'd offer the second calculation and see what they say. Remember, no jargon and KISS when framing your reply.

HTH and good luck.

Regards,
Ramiro

NOTICE: This electronic mail message and any files transmitted with it are intended
exclusively for the individual or entity to which it is addressed. The message,
together with any attachment, may contain confidential and/or privileged information.
Any unauthorized review, use, printing, saving, copying, disclosure or distribution
is strictly prohibited. If you have received this message in error, please
immediately advise the sender by reply email and delete all copies.

[Ramiro Camposagrado]

On Thu, 2 Jul 2009 11:30:48 -0500, Hal Merritt <HMer...@JACKHENRY.COM>
wrote:

Thanks Hal, and to everyone else who have responded.

I actually prefer you second calculation as well. I will present it to
the "committee" and as you have said: "Keep It As Simple as Possible".

Thanks again,

[Ted MacNEIL]

>one MIP

It's one MIPS.
The "s" is not pluralising the word it stands for "second".

The plural is imbedded in the "i": "instructionS".

-
Too busy driving to stop for gas!

[Kirk Wolf]

Pretty funny, but if that analogy doesn't work, then tell them that CPUs are
like spigots, and applications are like guys standing around with one or
more buckets. If they start to get that, then quickly switch analogies -
maybe we can compile a list? :-)

On Thu, Jul 2, 2009 at 11:12 AM, Tom Marchant <m42tom-...@yahoo.com>wrote:

>
> Let's see.... Your Ferrari is capable of going 200 MPH. It took five
> minutes to drive to the grocery store one mile away. How many MPH did it
> use?
>
>

----------------------------------------------------------------------

[Hal Merritt]

MIP = 'meaningless indication of power'. Singular, plural, or rate is just as meaningless. :-)

You will hear management and sales folks drop the 's' inappropriately: "This a 100 MIP box".

We are working in a management context so it's best to use words the same way they do. Besides, I was trying to express a rate as a quantity and was making a point as to how easy it is to get your numbers crossways.

>one MIP

NOTICE: This electronic mail message and any files transmitted with it are intended
exclusively for the individual or entity to which it is addressed. The message,
together with any attachment, may contain confidential and/or privileged information.
Any unauthorized review, use, printing, saving, copying, disclosure or distribution
is strictly prohibited. If you have received this message in error, please
immediately advise the sender by reply email and delete all copies.

----------------------------------------------------------------------

[Paul Gilmartin]

On Thu, 2 Jul 2009 17:26:03 +0000, Ted MacNEIL wrote:

>>one MIP
>
>It's one MIPS.
>The "s" is not pluralising the word it stands for "second".
>
>The plural is imbedded in the "i": "instructionS".
>

Ah, but do the medias report that the datas affirm that usage?

-- gil

[Ted MacNEIL]

>We are working in a management context so it's best to use words the same way they do.

I disagree with that.
Are you telling me that 'management context' is allowed to be technically inaccurate?

It's one thing to 'dumb it down'; it's another to be wrong.

-
Too busy driving to stop for gas!

----------------------------------------------------------------------

[Jeff Holst]

It may not be relevant to this particular application, but it is often important
to look at the big picture. Years ago, a client I was supporting had a batch
job that ran extremely long. Analysis revealed that most of the time was spent
in a calculation of the penalty for early withdrawal that would be imposed if
money was withdrawn from CD before it reached maturity. This was done so
that the CICS application could simply display the value when a depositor
asked for the information. It turns out that this information was being
requested for a tiny percentage of the accounts each day, but the calculation
was being done for every account every day.

The soution: Move the calculation to the CICS application. Yes, it caused the
CICS application to use more CPU and run a little bit longer. However it shaved
hours of run time and lots of CPU time from the batch job.

[John A Pershing Jr]

Stick with CPU time. What your "Cost Avoidance Committee" seems to
want, rather tha MIPS, is "instruction count" or "path length".
However, the important metric is CPU time -- it doesn't matter whether a
given transaction uses fewer instructions (lower path length) where
these instructions are "fatter", or uses more instructions which are
"thinner", what matters is how long it takes for the transaction to make
it through the CPU.

Measuring transaction "cost" in CPU time *is* probably a good starting
place for a global tuning project. It will identify the "heavy"
transactions, so that your team can focus on optimizing the low hanging
fruit. Note, though, that there are transactions which are inherently
heavier than other transactions: this is not necessarily a problem!
Your analysis team needs to develop an understanding of why tran A is
taking twice as much CPU as tran B, and then decide whether this is a
legitimate problem or not.

As someone else noted, MIPS==meaningless indication of processor speed,
although this is not totally true. For instance, a FORTRAN application
*will* clock a much higher MIPS rate than a typical COBOL application;
this is merely due to the fact that typical FORTRAN apps tend to use
"skinnier" instructions (RR, RX) which shoot thru the pipeline at
tremendous speeds, whereas COBOL apps tend to use "fatter" instructions
(SS). This does not mean that your COBOL transactions should be recoded
in FORTRAN, though!

-jp