Re: Help with elementary CPU speed question

[Scott Ford]

Man, talk about a blast from the past 3081, 3090 , 9672 wow

Scott ford
www.identityforge.com

On Jul 24, 2012, at 2:49 PM, Martin Packer  wrote:

> s/300J/600J/ :-)
> 
> Cheers, Martin
> 
> Martin Packer,
> zChampion, Principal Systems Investigator,
> Worldwide Banking Center of Excellence, IBM
> 
> +44-7802-245-584
> 
> email: martin_pac...@uk.ibm.com
> 
> Twitter / Facebook IDs: MartinPacker
> Blog: 
> https://www.ibm.com/developerworks/mydeveloperworks/blogs/MartinPacker
> 
> 
> 
> From:
> Jon Butler 
> To:
> IBM-MAIN@listserv.ua.edu, 
> Date:
> 07/24/2012 07:24 PM
> Subject:
> Re: Help with elementary CPU speed question
> Sent by:
> IBM Mainframe Discussion List 
> 
> 
> 
> There was a 3090-180J uni that was rated at 23.5.  The 3090-300J (3+3) 
> screamed along at 117 MIPS (20MSU).
> The 9672 G6 -- 9672-Z17 -- had 1 CP and was rated at 200 MIPS (35MSU).
> The z900 -- 2064-1C1 -- had 1 CP and was rated at 250 MIPS (43MSU).  Tho 
> Turbo 2064-2C1 was 303 MIPS.
> A z/196 -- 2817-701, depending on the OS, is 1200 MIPS (150MSU).
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> 
> 
> 
> 
> 
> 
> 
> 
> Unless stated otherwise above:
> IBM United Kingdom Limited - Registered in England and Wales with number 
> 741598. 
> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
> 
> 
> 
> 
> 
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Help with elementary CPU speed question

[Martin Packer]

s/300J/600J/ :-)

Cheers, Martin

Martin Packer,
zChampion, Principal Systems Investigator,
Worldwide Banking Center of Excellence, IBM

+44-7802-245-584

email: martin_pac...@uk.ibm.com

Twitter / Facebook IDs: MartinPacker
Blog: 
https://www.ibm.com/developerworks/mydeveloperworks/blogs/MartinPacker



From:
Jon Butler 
To:
IBM-MAIN@listserv.ua.edu, 
Date:
07/24/2012 07:24 PM
Subject:
Re: Help with elementary CPU speed question
Sent by:
IBM Mainframe Discussion List 



There was a 3090-180J uni that was rated at 23.5.  The 3090-300J (3+3) 
screamed along at 117 MIPS (20MSU).
The 9672 G6 -- 9672-Z17 -- had 1 CP and was rated at 200 MIPS (35MSU).
The z900 -- 2064-1C1 -- had 1 CP and was rated at 250 MIPS (43MSU).  Tho 
Turbo 2064-2C1 was 303 MIPS.
A z/196 -- 2817-701, depending on the OS, is 1200 MIPS (150MSU).

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN








Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 
741598. 
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU






--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Help with elementary CPU speed question

[Jon Butler]

There was a 3090-180J uni that was rated at 23.5.  The 3090-300J (3+3) screamed 
along at 117 MIPS (20MSU).
The 9672 G6 -- 9672-Z17 -- had 1 CP and was rated at 200 MIPS (35MSU).
The z900 -- 2064-1C1 -- had 1 CP and was rated at 250 MIPS (43MSU).  Tho Turbo 
2064-2C1 was 303 MIPS.
A z/196 -- 2817-701, depending on the OS, is 1200 MIPS (150MSU).

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Help with elementary CPU speed question

[Timothy Sipples]

Mike Ward writes:
>This is one area where I really have a problem. It used to be
>back in the 370 days that if a machine was rated at 50 mips and
>you moved up to 100 mips you really noticed the difference in
>execution time I know I'm on a rant

Was there even a 100 MIPS uniprocessor model in the 370 days? I don't know,
but I know that less than 12 years ago the uniprocessor z900 was a bit
under 200 MIPS, and that was considered a fast machine. (And hasn't it been
a fantastic decade for mainframe core performance!)

There's tremendous flexibility in capacity configurations nowadays -- much
more than in the past. If you want fewer, "taller" engines, that's
available. Or the opposite. Or several somethings in between, in general.
You can choose whatever works best.

That said, with 80-way single machines available, the multiprocessor bridge
is now well crossed. :-) I recommend taking steps to tweak and to improve
workloads so that they aren't unduly burdened by the limits of single core
performance. Goodness knows IBM has done a lot of work in that area. CICS
Transaction Server is an excellent example among many.

There are limits in improvements and tweaks, of course. But better is still
better.


Timothy Sipples
Resident Enterprise Architect (Based in Singapore)
E-Mail: timothy.sipp...@us.ibm.com
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Help with elementary CPU speed question

[Ward, Mike S]

You really know your processors and how they work. I think the  only time I  
ran anything dual was in a 370/155AP. We ran VM/SP and OS/VS1.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Anne & Lynn Wheeler
Sent: Friday, July 20, 2012 11:44 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Help with elementary CPU speed question

mw...@ssfcu.org (Ward, Mike S) writes:
> This is one area where I really have a problem. It used to be back in
> the 370 days that if a machine was rated at 50 mips and you moved up
> to 100 mips you really noticed the difference in execution time. Today
> if you have a 100 mip machine (I know they're rated at msu's not mips)
> and you moved up to a dual with 160 mips you might be cutting your own
> throat. They may give you 2 processors each rated at 80 mips for a
> total of 160 mips. If your workload is such that it can't take
> advantage of dual processors then you have just dropped down to an 80
> mip machine when you used to have a 100 mip machine. I know I'm on a
> rant, but it happened to up and we were being pressured by the vendor
> to go to the dual processor and that we would be very happy. We
> weren't. (end of rant)

370s & for a few generations ... going from uniprocessor to dual-processor 
started off by slowing machine cycle of each processor down by 10% ... 
bascially allowing caches a little headroom to handle cross-cache invalidations 
from the other cache (store through processor caches, every store operation 
would also involve sending invalidation signal to the other cache for that 
cache line). So basic two-processor hardware ran at 1.8 times a single 
processor. Then operating system multiprocessor overhead would increase (back 
when single processor MVS "capture ratio" could be 50%) ... leaving even less 
cycles for application execution ... aka same exact 10mip uniprocessor would 
only start out only being 9mip processor in two processor mode.  Note that 
actual handling of cross-cache invalidation was over&above the 10% processor 
cycle slowdown (in real live operation, 10mip process running at 9mips ... 
would actually effectively have less than 9mips, further reduced by 
multiprocessor operating system overhead & cache overhead of handling 
cross-cache invalidation signals).

strategy with 3081 was to never again to offer single process at the high-end. 
this ran into a couple problems ... clone processor vendors were offering 
uniprocessor and ACP/TPF didn't have multiprocessor support. All sorts of 
unnatural acts were done to try an make a 3081 acceptable to ACP/TPF (and head 
off customer base all moving to clone processors). this is besides the issues 
outline here about comparison between 3081 and clone processors:
http://www.jfsowa.com/computer/memo125.htm

eventually there was 3083 (in large part for the ACP/TPF market) which was 
created by removing a processor from a 3081 (which is not as simple as you 
might think, processor 0 was at the top of the frame, so processor 1 in the 
middle of the frame would be the one removed ... but that made the frame 
dangerously top-heavy). Being only single processor, turning off the 
cross-cache 10% slowdown made the processor nearly 15% faster (than a processor 
in 3081).

combining two 3081s together for a four-process 3084 was big challenge ... 
singe it met that each processor cache would be getting cross-cache 
invalidation signals from three other caches (not just one). kernel storage use 
became significant ... so operating systems running on 3084 were cache-line 
sensitised ... all kernel storage was changed to align on cache-line boundaries 
and be multiples of cache-lines.  The problem was that if the start of end of 
one storage location was at the start of a cache-line and the start of a 
different storage location was at the end of the same cache-line ... the two 
different storage locations could be in use by different processors 
simultaneously. However, it represents only a single storage block for cache 
management ... and could result in cache "thrashing". The storage cache 
sensitivity change is claimed to improve 3084 throughput by 5-6% (minimizing 
cache line thrashing).

However, higher-end 370s processor throughput was quite sensitive to cache hit 
ratios ... which would be seriously affected by high-rate of asynchronous i/o 
interrupts. For my "resource manager" ... I did some hacks (at high i/o rates) 
turning off enabling for I/O interrupts for periods of time and then draining 
all pending I/O interrupts. I could demonstrate aggregate higher throughput 
(even I/O throughput) ... since the batching of I/O interrupts would have much 
higher processor throughput (because of better cache hit ratio) ... offsetting 
any delay in taking the interrupt (note part of 370/xa was attempting to 
address same issue w

Re: Help with elementary CPU speed question

[Anne & Lynn Wheeler]

mw...@ssfcu.org (Ward, Mike S) writes:
> This is one area where I really have a problem. It used to be back in
> the 370 days that if a machine was rated at 50 mips and you moved up
> to 100 mips you really noticed the difference in execution time. Today
> if you have a 100 mip machine (I know they're rated at msu's not mips)
> and you moved up to a dual with 160 mips you might be cutting your own
> throat. They may give you 2 processors each rated at 80 mips for a
> total of 160 mips. If your workload is such that it can't take
> advantage of dual processors then you have just dropped down to an 80
> mip machine when you used to have a 100 mip machine. I know I'm on a
> rant, but it happened to up and we were being pressured by the vendor
> to go to the dual processor and that we would be very happy. We
> weren't. (end of rant)

370s & for a few generations ... going from uniprocessor to
dual-processor started off by slowing machine cycle of each processor
down by 10% ... bascially allowing caches a little headroom to handle
cross-cache invalidations from the other cache (store through processor
caches, every store operation would also involve sending invalidation
signal to the other cache for that cache line). So basic two-processor
hardware ran at 1.8 times a single processor. Then operating system
multiprocessor overhead would increase (back when single processor MVS
"capture ratio" could be 50%) ... leaving even less cycles for
application execution ... aka same exact 10mip uniprocessor would only
start out only being 9mip processor in two processor mode.  Note that
actual handling of cross-cache invalidation was over&above the 10%
processor cycle slowdown (in real live operation, 10mip process running
at 9mips ... would actually effectively have less than 9mips, further
reduced by multiprocessor operating system overhead & cache overhead of
handling cross-cache invalidation signals).

strategy with 3081 was to never again to offer single process at the
high-end. this ran into a couple problems ... clone processor vendors
were offering uniprocessor and ACP/TPF didn't have multiprocessor
support. All sorts of unnatural acts were done to try an make a 3081
acceptable to ACP/TPF (and head off customer base all moving to clone
processors). this is besides the issues outline here about comparison
between 3081 and clone processors:
http://www.jfsowa.com/computer/memo125.htm

eventually there was 3083 (in large part for the ACP/TPF market) which
was created by removing a processor from a 3081 (which is not as simple
as you might think, processor 0 was at the top of the frame, so
processor 1 in the middle of the frame would be the one removed ... but
that made the frame dangerously top-heavy). Being only single processor,
turning off the cross-cache 10% slowdown made the processor nearly 15%
faster (than a processor in 3081).

combining two 3081s together for a four-process 3084 was big challenge
... singe it met that each processor cache would be getting cross-cache
invalidation signals from three other caches (not just one). kernel
storage use became significant ... so operating systems running on 3084
were cache-line sensitised ... all kernel storage was changed to align
on cache-line boundaries and be multiples of cache-lines.  The problem
was that if the start of end of one storage location was at the start of
a cache-line and the start of a different storage location was at the
end of the same cache-line ... the two different storage locations could
be in use by different processors simultaneously. However, it represents
only a single storage block for cache management ... and could result in
cache "thrashing". The storage cache sensitivity change is claimed to
improve 3084 throughput by 5-6% (minimizing cache line thrashing).

However, higher-end 370s processor throughput was quite sensitive to
cache hit ratios ... which would be seriously affected by high-rate of
asynchronous i/o interrupts. For my "resource manager" ... I did some
hacks (at high i/o rates) turning off enabling for I/O interrupts for
periods of time and then draining all pending I/O interrupts. I could
demonstrate aggregate higher throughput (even I/O throughput) ... since
the batching of I/O interrupts would have much higher processor
throughput (because of better cache hit ratio) ... offsetting any delay
in taking the interrupt (note part of 370/xa was attempting to address
same issue with various kinds of i/o queuing in the hardware).

When I first did two-processor 370 support ... I was able to deploy in
production environemnt ... two processors running more than twice MIP
rate as single processor ... including processor cycle only running at
.9 that of single processor. Some games with cache affinity allowed
improved cache hit ratio ... which more than offset the 10% slowdown in
processor cycle.

-- 
virtualization experience starting Jan1968, online at home since Mar1970

-

Re: Help with elementary CPU speed question

[Ward, Mike S]

This is one area where I really have a problem. It used to be back in the 370 
days that if a machine was rated at 50 mips and you moved up to 100 mips you 
really noticed the difference in execution time. Today if you have a 100 mip 
machine (I know they're rated at msu's not mips) and you moved up to a dual 
with 160 mips you might be cutting your own throat. They may give you 2 
processors each rated at 80 mips for a total of 160 mips. If your workload is 
such that it can't take advantage of dual processors then you have just dropped 
down to an 80 mip machine when you used to have a 100 mip machine. I know I'm 
on a rant, but it happened to up and we were being pressured by the vendor to 
go to the dual processor and that we would be very happy. We weren't. (end of 
rant)

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Charles Mills
Sent: Tuesday, July 17, 2012 8:53 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Help with elementary CPU speed question

I have gotten dragged into a CPU performance question; a field I know little 
about.



I run a test on a 2094-722. It is rated at 19778 SU/Second. The job consumes
.146 CPU seconds total.



I run the same job on a 2064-2C3. It is rated at 13378 SU/Second. All other 
things being roughly equal, should I expect that the job will consume 1.48
(19778/13378) times as much CPU time, or .216 CPU seconds?



Is my logic right, or am I off somewhere? I'm not worried about a millisecond 
or two; just the broad strokes.



Thanks,

Charles


--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@listserv.ua.edu with the message: INFO IBM-MAIN

==
This email, and any files transmitted with it, is confidential and intended 
solely for the use of the individual or entity to which it is addressed. If you 
have received this email in error, please notify the system manager. This 
message contains confidential information and is intended only for the 
individual named. If you are not the named addressee, you should not 
disseminate, distribute or copy this e-mail. Please notify the sender 
immediately by e-mail if you have received this message by mistake and delete 
this e-mail from your system. If you are not the intended recipient, you are 
notified that disclosing, copying, distributing or taking any action in 
reliance on the contents of this information is strictly prohibited.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Help with elementary CPU speed question

[Dave Barry]

Tom,

Thanks for catching my mistake.  I read too quickly.  Yes, the SRM constants 
aren't speed ratings at all.

The part that is relevant is this:  the ratio of MIPS per CP is the best way 
for Charles to estimate the CPU time of his job on the new processor.  As 
another lister pointed out, batch jobs generally run on a single TCB, so they 
can only be served as fast as a single CP can deliver.

I took the average MIPS/CP from one of Cheryl Watson's CPU charts just to give 
a simple example.  The result should be close, although in practice I have 
always had to compare actual job CPU times and derive the local fudge factor as 
closely as possible through experimentation.

db  

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Tom Marchant
Sent: Wednesday, July 18, 2012 7:41 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Help with elementary CPU speed question

On Wed, 18 Jul 2012 18:47:13 -0400, Dave Barry wrote:


>In theory, you divide the rated SU/second by the number of processors 
>giving SUs/processor/second, adjusting for "MP effect" overhead.

No, the SU/second is called the SRM constant and it is used to convert CPU time 
(in seconds) to service units.  
It is already adjusted for the MP effect.  Mark gave a reference earlier that 
describes this.  Here it is again:

http://publib.boulder.ibm.com/infocenter/zos/v1r11/index.jsp?topic=/com.ibm.zos.r11.erba900/erbzpm8020.htm

http://tinyurl.com/ccsgeb4

>273.8 (2064-2C3) divided by 426.1 (2094-722) equals 0.643.

Where did you get those numbers?  
The SRM constant for a 2094-722 is 19,777.5031 SU/second The SRM constant for a 
2064-2C3 is 13,377.9264 SU/second

Here are a few others.  It should be obvious that it does not make sense to 
divide by the number of
processors:

2064-2C1  (1 CP)  14692.3783
2064-2C2  (2 CP)  13961.6056
2064-2C3  (3 CP)  13377.9264
2064-2C4  (4 CP)  13082.5838

--
Tom Marchant

--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Help with elementary CPU speed question

[Jon Butler]

Charles,

Your summation is correct.  But there are no more mainframes that run in REAL 
modethey all run in LPAR mode.  If you want to assume you are paying only 
for CPU time, then you can probably estimate that your new bill will be 
calculated as 1.48*T*c, where T is the z9 CPU Time, and c is the z900 cost per 
unit of work.  However...as always...it depends.  

Are you charged only per "MIP"?  Is this a CPU intensive job?  If you pay for 
I/O with ESCON on the z900 you will pay less if the job runs on a z9 with 
FICON.IBM tell clients that they can run identical workloads cheaper on new 
CECs because of the overall increase in efficiency of the the newer hardware.   
If that's true, going backwards in hardware would cost you more to run the same 
workload.  But at the end of the day it will boil down to the charging 
algorithms.   Are you moving from one CEC to another at the same service 
provider?  If so, they probably have different algorithms on each CEC so the 
same job costs the same amount, even though it runs 8 times slower!  

The only way you are going to find out the real cost is to run the workload and 
see what happens.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Help with elementary CPU speed question

[Timothy Sipples]

I'm enjoying this dialog. I agree with Shmuel that if it were totally
simple to estimate capacity requirements across model generations then each
new model would be quite disappointing. And we wouldn't even be able to do
certain things in real world volumes such as cryptography, which is rather
important of course. Processor performance improvements often yield varying
benefits depending on the particular workloads.

I suppose then there's the question of whether divergence from capacity and
performance forecasts matter. Sometimes yes, sometimes no.

We deal with statistical means, medians, standard deviations,
distributions, and percentiles all the time in our everyday lives. For
example, automobiles have published miles per gallon (or liters per 100
Kilometers) fuel efficiency ratings, typically one number for stop-and-go
city driving and another for highway driving. Your results will probably be
different than the published numbers, resulting in higher or lower fuel
costs and consequent environmental impact. But those differences may or may
not matter. (They matter less in the U.S. than in Belgium, ceteris
paribus.) Manufacturers and regulators are now struggling with how and
whether to publish such numbers for hybrid and electric vehicles. In other
words, there's a significant technology breakthrough in vehicle design, and
the existing efficiency metric is at least somewhat harder to apply and to
interpret. (Obviously banning hybrid and electric vehicles because it's
harder to assign them single efficiency numbers would be ridiculous.)

I also agree that sometimes you need a little expert help in such matters.
(Maybe even a trial or benchmark.) The amount of help should be in
proportion to the risks and rewards, though. Vehicle fleet buyers probably
need to worry more about fuel consumption results than lower volume buyers,
for example. And sometimes that help isn't really technical. I can't even
begin to list all the times when someone expends a great deal of effort
trying to optimize some aspect of computing when the actual, real, best
solution involved somebody just agreeing to change a number in a
spreadsheet or contract. Or when somebody deploys armies (comparatively
speaking) to tweak their mainframe to squeeze out 0.02% more throughput at
the same time that they're spending (and wasting) millions on everything
else flooding into their data centers. Maybe (maybe) they should do both,
but there are priorities!

Then again, I've occasionally been known to spend countless hours shopping
for a US$20 product in search of a coupon, promotion, and/or rebate to
drive the price all the way down to $19.68. I also couldn't resist buying
two cans of pumpkin at 19 cents each simply because ... they were only 19
cents each! Those cans then sat on my shelf for two years until I gave them
away. We humans aren't always rational, are we? :-)


Timothy Sipples
Resident Enterprise Architect (Based in Singapore)
E-Mail: timothy.sipp...@us.ibm.com
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Help with elementary CPU speed question

[Chris Mason]

Steve

For my sins, I started work in an industrial research laboratory.

One time the laboratory was having some sort of open day[1] and one of my 
colleagues had a printed card announcing the rate of migration of chlorine ions 
through magnetite which must have had some bearing upon the apparatus 
supposedly on show.

Although he was a PhD, this key result, thought to be of great importance for 
understanding corrosion at high temperatures and pressures, was presented as, 
relying approximately on your numbers, 1.48 +/- 0.4.

The point, something I learned in my *school* physics laboratory (or was it my 
school chemistry laboratory!), was to adjust the precision of a reported 
measurement to match the degree of uncertainty.

If my physics master (or my chemistry master) had been presented with "1.48 +/- 
0.4.", I would have suffered some severe "marking down"!

In case my point has been missed, with something like +/- 0.4 uncertainty, you 
should have said the following:

"... the average the z9 is 1.5 times faster ... ."

-

[1] This reminds me of another sort of "open day" held in the Royal Festival 
Hall. I was obliged to roll a rack of equipment across the main hall between 
the seats and the stage where Mstislav Rostropovich was rehearsing - actually 
and necessarily taking a short break. He didn't give me the friendliest of 
looks as I tried to give an apologetic look in return!

-

Chris Mason

On Wed, 18 Jul 2012 22:43:30 +, Finch, Steve (ES - Mainframe) 
 wrote:

> I would say that on the average the z9 is 1.48 times faster , but that number 
> depends on what the program is doing.  The number could be 1.1 to 1.8 
> depending on what the batch program is doing.  It's the old - your mileage 
> will vary comment 
 
> The purpose of PCR is to deal with the flux factor

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Help with elementary CPU speed question

[Shane Ginnane]

I'd be inclined to use the relative LSPR ratios - which happens to roughly 
correspond to the UP ratio of the machines.
Seems intuitively reasonable.

Wrap some weasel words around your recommendation (there are some examples on 
the LPSR site) in case it all goes pear-shaped, and walk away contented.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Help with elementary CPU speed question

[Dave Barry]

Charles,

In theory, you divide the rated SU/second by the number of processors giving 
SUs/processor/second, adjusting for "MP effect" overhead.  Similarly, you could 
use MIPS/processor such that: 

273.8 (2064-2C3) divided by 426.1 (2094-722) equals 0.643.

0.146 seconds times 0.643 equals 0.0939 seconds

Subtle factors render the ratio less than exact, especially with very small 
values, but your tests should prove to be in the ballpark.  Test by averaging 
several runs and let us know how it turns out.

db

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Charles Mills
Sent: Tuesday, July 17, 2012 9:53 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Help with elementary CPU speed question

I have gotten dragged into a CPU performance question; a field I know little 
about.

 

I run a test on a 2094-722. It is rated at 19778 SU/Second. The job consumes
.146 CPU seconds total.

 

I run the same job on a 2064-2C3. It is rated at 13378 SU/Second. All other 
things being roughly equal, should I expect that the job will consume 1.48
(19778/13378) times as much CPU time, or .216 CPU seconds?

 

Is my logic right, or am I off somewhere? I'm not worried about a millisecond 
or two; just the broad strokes.

 

Thanks,

Charles 


--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Help with elementary CPU speed question

[Finch, Steve (ES - Mainframe)]

I would say that on the average the z9 is 1.48 times faster , but that number 
depends on what the program is doing.  The number could be 1.1 to 1.8 depending 
on what the batch program is doing.  It's the old - your mileage will vary 
comment

The purpose of PCR is to deal with the flux factor 

Steve Finch

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Charles Mills
Sent: Wednesday, July 18, 2012 2:46 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Help with elementary CPU speed question

Jon, thanks for the thoughtful reply. Much appreciated.

You say the z900 is 1/8 as fast (powerful, whatever, fill in your favorite 
word) as the z9. That's a combination of two factors, right? Each CPU on the z9 
is 1.48 times as fast as those on the z900, and in addition the -722 has 22 of 
them, while the -2C3 has only three, is that right? I am mostly interested at 
this moment in CPU time. I know it's not the only thing, and it's not the same 
thing as wall clock time, but it is what the company is going to be billed for 
so it is a (the?) critical factor at this moment. So I think my focusing on 
relative CPU speed rather than total "box power" (CPU's only, or CPU's and I/O) 
is correct at this time. Any thoughts?

Charles
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Jon Butler
Sent: Wednesday, July 18, 2012 11:12 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Help with elementary CPU speed question

As has been pointed out, there are many IBM tools such as zPCR that you can 
download to help with this exercise.  The tools require either a good estimate 
or RMF data from the LPARs to give you an accurate comparison.  In running one 
job anything can happen to distort the figures.

However, I think a rough calculation without regard to the other work in the 
LPARs on the several CECs can give you an idea of what to expect.  If we make 
the assumption that both CECs are running a similar workloadnot bloody 
likely give the CEC's design difference, disk drives, I/O configs, WLM 
settings, OS version, etcbut using numbers from the latest MIPS ratings 
here is what you are up against:

z9/722 rated at 1226 MSU
z900/2C3 rated at 144 MSU

I'd guess your job is going to run 1226/144 or 8 times slower.  Let us know 
what happens.  Of course if the z9 is running at 95% and the z900 at 5%, your 
job may be faster on the older CEC

--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Help with elementary CPU speed question

[Charles Mills]

> It makes no sense to try to calculate the CPU utilization on one system 
> compared to another by taking a ratio of the total throughput when 
> one has 22 processors and the other has 3.

Unless the programmer has done one heckuva job exploiting parallelization. 

Charles

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Tom Marchant
Sent: Wednesday, July 18, 2012 12:35 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Help with elementary CPU speed question

On Wed, 18 Jul 2012 13:12:06 -0500, Jon Butler wrote:

>...  using numbers from the latest MIPS ratings here is what 
>you are up against:
>
>z9/722 rated at 1226 MSU
>z900/2C3 rated at 144 MSU
>
>I'd guess your job is going to run 1226/144 or 8 times slower.

ROTFLMAO

MIPS?  Then you quote MSU?  If you are going to use LSPR data, 
why not quote ITR?  MSUs have been altered by IBM marketing to 
give the "technology dividend".

And you are totally ignorong the number of processors.  It makes no 
sense to try to calculate the CPU utilization on one system 
compared to another by taking a ratio of the total throughput when 
one has 22 processors and the other has 3.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Help with elementary CPU speed question

[Tom Marchant]

On Wed, 18 Jul 2012 13:12:06 -0500, Jon Butler wrote:

>...  using numbers from the latest MIPS ratings here is what 
>you are up against:
>
>z9/722 rated at 1226 MSU
>z900/2C3 rated at 144 MSU
>
>I'd guess your job is going to run 1226/144 or 8 times slower.

ROTFLMAO

MIPS?  Then you quote MSU?  If you are going to use LSPR data, 
why not quote ITR?  MSUs have been altered by IBM marketing to 
give the "technology dividend".

And you are totally ignorong the number of processors.  It makes no 
sense to try to calculate the CPU utilization on one system 
compared to another by taking a ratio of the total throughput when 
one has 22 processors and the other has 3.

-- 
Tom Marchant

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Help with elementary CPU speed question

[Gibney, Dave]

Like it or not, most batch jobs are largely single CPU bound. They do not often 
multi-task. So I would suggest you use the ratio of the single processor 
numbers from LSPR.  Still there are many ways YMMV

Dave Gibney
Information Technology Services
Washington State University


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> On Behalf Of Charles Mills
> Sent: Wednesday, July 18, 2012 11:46 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Help with elementary CPU speed question
> 
> Jon, thanks for the thoughtful reply. Much appreciated.
> 
> You say the z900 is 1/8 as fast (powerful, whatever, fill in your favorite 
> word)
> as the z9. That's a combination of two factors, right? Each CPU on the z9 is
> 1.48 times as fast as those on the z900, and in addition the -722 has 22 of
> them, while the -2C3 has only three, is that right? I am mostly interested at
> this moment in CPU time. I know it's not the only thing, and it's not the same
> thing as wall clock time, but it is what the company is going to be billed 
> for so
> it is a (the?) critical factor at this moment. So I think my focusing on 
> relative
> CPU speed rather than total "box power" (CPU's only, or CPU's and I/O) is
> correct at this time. Any thoughts?
> 
> Charles
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> On Behalf Of Jon Butler
> Sent: Wednesday, July 18, 2012 11:12 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Help with elementary CPU speed question
> 
> As has been pointed out, there are many IBM tools such as zPCR that you can
> download to help with this exercise.  The tools require either a good estimate
> or RMF data from the LPARs to give you an accurate comparison.  In running
> one job anything can happen to distort the figures.
> 
> However, I think a rough calculation without regard to the other work in the
> LPARs on the several CECs can give you an idea of what to expect.  If we make
> the assumption that both CECs are running a similar workloadnot bloody
> likely give the CEC's design difference, disk drives, I/O configs, WLM 
> settings,
> OS version, etcbut using numbers from the latest MIPS ratings here is what
> you are up against:
> 
> z9/722 rated at 1226 MSU
> z900/2C3 rated at 144 MSU
> 
> I'd guess your job is going to run 1226/144 or 8 times slower.  Let us know
> what happens.  Of course if the z9 is running at 95% and the z900 at 5%, your
> job may be faster on the older CEC
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Help with elementary CPU speed question

[Charles Mills]

Jon, thanks for the thoughtful reply. Much appreciated.

You say the z900 is 1/8 as fast (powerful, whatever, fill in your favorite 
word) as the z9. That's a combination of two factors, right? Each CPU on the z9 
is 1.48 times as fast as those on the z900, and in addition the -722 has 22 of 
them, while the -2C3 has only three, is that right? I am mostly interested at 
this moment in CPU time. I know it's not the only thing, and it's not the same 
thing as wall clock time, but it is what the company is going to be billed for 
so it is a (the?) critical factor at this moment. So I think my focusing on 
relative CPU speed rather than total "box power" (CPU's only, or CPU's and I/O) 
is correct at this time. Any thoughts?

Charles
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Jon Butler
Sent: Wednesday, July 18, 2012 11:12 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Help with elementary CPU speed question

As has been pointed out, there are many IBM tools such as zPCR that you can 
download to help with this exercise.  The tools require either a good estimate 
or RMF data from the LPARs to give you an accurate comparison.  In running one 
job anything can happen to distort the figures.

However, I think a rough calculation without regard to the other work in the 
LPARs on the several CECs can give you an idea of what to expect.  If we make 
the assumption that both CECs are running a similar workloadnot bloody 
likely give the CEC's design difference, disk drives, I/O configs, WLM 
settings, OS version, etcbut using numbers from the latest MIPS ratings 
here is what you are up against:

z9/722 rated at 1226 MSU
z900/2C3 rated at 144 MSU

I'd guess your job is going to run 1226/144 or 8 times slower.  Let us know 
what happens.  Of course if the z9 is running at 95% and the z900 at 5%, your 
job may be faster on the older CEC

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Help with elementary CPU speed question

[Hal Merritt]

Short answer: most likely not. 

Slightly longer answer: although all CPU's wait at the same speed, they vary in 
most everything else. 



 
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Charles Mills
Sent: Tuesday, July 17, 2012 8:53 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Help with elementary CPU speed question

I have gotten dragged into a CPU performance question; a field I know little 
about.

 

I run a test on a 2094-722. It is rated at 19778 SU/Second. The job consumes
.146 CPU seconds total.

 

I run the same job on a 2064-2C3. It is rated at 13378 SU/Second. All other 
things being roughly equal, should I expect that the job will consume 1.48
(19778/13378) times as much CPU time, or .216 CPU seconds?

 

Is my logic right, or am I off somewhere? I'm not worried about a millisecond 
or two; just the broad strokes.

 

Thanks,

Charles 


--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@listserv.ua.edu with the message: INFO IBM-MAIN
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.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Help with elementary CPU speed question

[Jon Butler]

As has been pointed out, there are many IBM tools such as zPCR that you can 
download to help with this exercise.  The tools require either a good estimate 
or RMF data from the LPARs to give you an accurate comparison.  In running one 
job anything can happen to distort the figures.

However, I think a rough calculation without regard to the other work in the 
LPARs on the several CECs can give you an idea of what to expect.  If we make 
the assumption that both CECs are running a similar workloadnot bloody 
likely give the CEC's design difference, disk drives, I/O configs, WLM 
settings, OS version, etcbut using numbers from the latest MIPS ratings 
here is what you are up against:

z9/722 rated at 1226 MSU
z900/2C3 rated at 144 MSU

I'd guess your job is going to run 1226/144 or 8 times slower.  Let us know 
what happens.  Of course if the z9 is running at 95% and the z900 at 5%, your 
job may be faster on the older CEC

Remember, objects are always closer than they appear in the mirror, and your 
actual mileage will vary.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Help with elementary CPU speed question

[John Gilmore]

Another problem with Peter Farley's formulation of this issue is his
use of the phrase "normally skilled professional application
programmer".  The question just what skills such a person should have
is controversial.  The question what skills they do in fact usually
have is less so.

A great figure in computing once observed that in his experience COBOL
applications programmers could be divided into two disjoint subsets.
There were those, he said, who did not know what binary search was;
and then there were those who did and were proud of it.

This of course is caricature.  I know applications programmers who are
good technicians.  But like all good caricature it exaggerates without
really misrepresenting.

John Gilmore, Ashland, MA 01721 - USA

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Help with elementary CPU speed question

[Shmuel Metz (Seymour J.)]

In
<985915eee6984740ae93f8495c624c6c21e5c49...@jscpcwexmaa1.bsg.ad.adp.com>,
on 07/17/2012
   at 12:04 PM, "Farley, Peter x23353" 
said:

>t SHOULD NOT be necessary to have "considerable statistical prowess"
>or have access to DCOLLECT output (which most normal application
>programmers DO NOT HAVE) or to have access to a statistical package
>like MXG or any other such beast in order to answer simple questions
>like "does machine X have enough CPU horsepower to run YYY instances
>of program ZZZ at the same time?" or "how much CPU and elapsed time
>will the new changes in program ZZZ consume when moved into
>production?".  These are questions that a normally skilled
>professional application programmer ought to be able to provide a
>reasonable answer to -- but we cannot, because "it depends...".

Yes, and the second law of thermodynamics is unfair. The universe is
what it is.

>I'm not advocating a return to the single-non-pipelined CPU days 
>of yore, just for SOMEONE (not me since I am obviously not 
>qualified) to come up with a REPEATABLE way to measure a 
>program's real performance with only one or two 
>production-level test runs.

You may not be advocating it, but that's what it would take.

-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 Atid/2
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Help with elementary CPU speed question

[Charles Mills]

If we were contemplating buying a computer, perhaps.

I am trying to determine the cost of rented time to support a particular
workload, and in fact whether it will support it at all.

Charles

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Gibney, Dave
Sent: Tuesday, July 17, 2012 1:37 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Help with elementary CPU speed question

I agree. IBM, or more likely, Charles' business partner should do such
modeling for free.

Dave Gibney
Information Technology Services
Washington State University

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] 
> On Behalf Of Rob Schramm
> Sent: Tuesday, July 17, 2012 10:02 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Help with elementary CPU speed question
> 
> The LSPR numbers give a fairly decent indication of performance based 
> upon various workloads.  Of course you have to know the kind of work 
> that your shop does.
> 
> Kirk is correct.  IBM has a couple of tools for doing CPU projections 
> based upon the current numbers and projecting it onto various 
> processor configurations... available on resource link.
> 
> 
> my old company would do performance  projections for their customers 
> as part of their value add  
> Rob Schramm
> Senior Systems Consultant
> Imperium Group
> 
> 
> 
> On Tue, Jul 17, 2012 at 12:47 PM, Skip Robinson
> wrote:
> 
> > Brings to mind the by-far most often quoted performance standard in 
> > the
> > U.S.: the MPG rating attached to every new car sold in this country. 
> > More than merely 'it depends', MPG has two ratings displayed: 
> > highway and non-highway. What you actually experience *should* fall 
> > somewhere in between. I've never heard a complaint from anyone whose MPG
is too high.
> > In the case of too low, we've had some highly publicized lawsuits 
> > hereabouts.
> >
> >  Auto makers love the wiggle phrase "your actual 
> > mileage may vary". Duh. Of course it will vary. That's why MPG is 
> > given as a range. What they are loathe to admit is that "your actual 
> > mileage may differ" from the advertized range. Ouch. Lawyer up, 
> > drivers. Clear your court calendar. In the latest publicized 
> > lawsuit, the auto maker is attempting to toss the whole controversy 
> > onto the Feds, who actually produce and publish the numbers. Good 
> > luck with that. 
> >
> > Did Whitehead assert that this is a virtual Friday?
> >
> > .
> > .
> > JO.Skip Robinson
> > SCE Infrastructure Technology Services Electric Dragon Team Paddler 
> > SHARE MVS Program Co-Manager
> > 626-302-7535 Office
> > 323-715-0595 Mobile
> > jo.skip.robin...@sce.com
> >
> >
> >
> > From:   John Gilmore 
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Date:   07/17/2012 09:21 AM
> > Subject:Re: Help with elementary CPU speed question
> > Sent by:IBM Mainframe Discussion List  m...@listserv.ua.edu>
> >
> >
> >
> > I have some sympathy with Peter Farley's 'rant'
> >
> > Things should perhaps be otherwise.  They are not, and I see no 
> > immediate prospect that they will become so.
> >
> > There is also another way to look at Peter's view.  Whitehead long 
> > ago warned us that a complex question cannot be simplified by asking 
> > simple questions about it.
> >
> > John Gilmore, Ashland, MA 01721 -USA
> >
> >
> > 
> > -- For IBM-MAIN subscribe / signoff / archive access instructions, 
> > send email to lists...@listserv.ua.edu with the message: INFO 
> > IBM-MAIN
> >
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send 
> email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions, send email
to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Help with elementary CPU speed question

[Gibney, Dave]

I agree. IBM, or more likely, Charles' business partner should do such modeling 
for free.

Dave Gibney
Information Technology Services
Washington State University

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> On Behalf Of Rob Schramm
> Sent: Tuesday, July 17, 2012 10:02 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Help with elementary CPU speed question
> 
> The LSPR numbers give a fairly decent indication of performance based upon
> various workloads.  Of course you have to know the kind of work that your
> shop does.
> 
> Kirk is correct.  IBM has a couple of tools for doing CPU projections based
> upon the current numbers and projecting it onto various processor
> configurations... available on resource link.
> 
> 
> my old company would do performance  projections for their customers as
> part of their value add
>  
> Rob Schramm
> Senior Systems Consultant
> Imperium Group
> 
> 
> 
> On Tue, Jul 17, 2012 at 12:47 PM, Skip Robinson
> wrote:
> 
> > Brings to mind the by-far most often quoted performance standard in the
> > U.S.: the MPG rating attached to every new car sold in this country. More
> > than merely 'it depends', MPG has two ratings displayed: highway and
> > non-highway. What you actually experience *should* fall somewhere in
> > between. I've never heard a complaint from anyone whose MPG is too high.
> > In the case of too low, we've had some highly publicized lawsuits
> > hereabouts.
> >
> >  Auto makers love the wiggle phrase "your actual mileage
> > may vary". Duh. Of course it will vary. That's why MPG is given as a
> > range. What they are loathe to admit is that "your actual mileage may
> > differ" from the advertized range. Ouch. Lawyer up, drivers. Clear your
> > court calendar. In the latest publicized lawsuit, the auto maker is
> > attempting to toss the whole controversy onto the Feds, who actually
> > produce and publish the numbers. Good luck with that. 
> >
> > Did Whitehead assert that this is a virtual Friday?
> >
> > .
> > .
> > JO.Skip Robinson
> > SCE Infrastructure Technology Services
> > Electric Dragon Team Paddler
> > SHARE MVS Program Co-Manager
> > 626-302-7535 Office
> > 323-715-0595 Mobile
> > jo.skip.robin...@sce.com
> >
> >
> >
> > From:   John Gilmore 
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Date:   07/17/2012 09:21 AM
> > Subject:Re: Help with elementary CPU speed question
> > Sent by:IBM Mainframe Discussion List  m...@listserv.ua.edu>
> >
> >
> >
> > I have some sympathy with Peter Farley's 'rant'
> >
> > Things should perhaps be otherwise.  They are not, and I see no
> > immediate prospect that they will become so.
> >
> > There is also another way to look at Peter's view.  Whitehead long ago
> > warned us that a complex question cannot be simplified by asking
> > simple questions about it.
> >
> > John Gilmore, Ashland, MA 01721 -USA
> >
> >
> > --
> > For IBM-MAIN subscribe / signoff / archive access instructions,
> > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> >
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Help with elementary CPU speed question

[Rob Schramm]

The LSPR numbers give a fairly decent indication of performance based upon
various workloads.  Of course you have to know the kind of work that your
shop does.

Kirk is correct.  IBM has a couple of tools for doing CPU projections based
upon the current numbers and projecting it onto various processor
configurations... available on resource link.


my old company would do performance  projections for their customers as
part of their value add
wrote:

> Brings to mind the by-far most often quoted performance standard in the
> U.S.: the MPG rating attached to every new car sold in this country. More
> than merely 'it depends', MPG has two ratings displayed: highway and
> non-highway. What you actually experience *should* fall somewhere in
> between. I've never heard a complaint from anyone whose MPG is too high.
> In the case of too low, we've had some highly publicized lawsuits
> hereabouts.
>
>  Auto makers love the wiggle phrase "your actual mileage
> may vary". Duh. Of course it will vary. That's why MPG is given as a
> range. What they are loathe to admit is that "your actual mileage may
> differ" from the advertized range. Ouch. Lawyer up, drivers. Clear your
> court calendar. In the latest publicized lawsuit, the auto maker is
> attempting to toss the whole controversy onto the Feds, who actually
> produce and publish the numbers. Good luck with that. 
>
> Did Whitehead assert that this is a virtual Friday?
>
> .
> .
> JO.Skip Robinson
> SCE Infrastructure Technology Services
> Electric Dragon Team Paddler
> SHARE MVS Program Co-Manager
> 626-302-7535 Office
> 323-715-0595 Mobile
> jo.skip.robin...@sce.com
>
>
>
> From:   John Gilmore 
> To: IBM-MAIN@LISTSERV.UA.EDU
> Date:   07/17/2012 09:21 AM
> Subject:Re: Help with elementary CPU speed question
> Sent by:IBM Mainframe Discussion List 
>
>
>
> I have some sympathy with Peter Farley's 'rant'
>
> Things should perhaps be otherwise.  They are not, and I see no
> immediate prospect that they will become so.
>
> There is also another way to look at Peter's view.  Whitehead long ago
> warned us that a complex question cannot be simplified by asking
> simple questions about it.
>
> John Gilmore, Ashland, MA 01721 -USA
>
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Help with elementary CPU speed question

[Skip Robinson]

Brings to mind the by-far most often quoted performance standard in the 
U.S.: the MPG rating attached to every new car sold in this country. More 
than merely 'it depends', MPG has two ratings displayed: highway and 
non-highway. What you actually experience *should* fall somewhere in 
between. I've never heard a complaint from anyone whose MPG is too high. 
In the case of too low, we've had some highly publicized lawsuits 
hereabouts. 

 Auto makers love the wiggle phrase "your actual mileage 
may vary". Duh. Of course it will vary. That's why MPG is given as a 
range. What they are loathe to admit is that "your actual mileage may 
differ" from the advertized range. Ouch. Lawyer up, drivers. Clear your 
court calendar. In the latest publicized lawsuit, the auto maker is 
attempting to toss the whole controversy onto the Feds, who actually 
produce and publish the numbers. Good luck with that. 

Did Whitehead assert that this is a virtual Friday? 

.
.
JO.Skip Robinson
SCE Infrastructure Technology Services
Electric Dragon Team Paddler 
SHARE MVS Program Co-Manager
626-302-7535 Office
323-715-0595 Mobile
jo.skip.robin...@sce.com



From:   John Gilmore 
To: IBM-MAIN@LISTSERV.UA.EDU
Date:   07/17/2012 09:21 AM
Subject:    Re: Help with elementary CPU speed question
Sent by:IBM Mainframe Discussion List 



I have some sympathy with Peter Farley's 'rant'

Things should perhaps be otherwise.  They are not, and I see no
immediate prospect that they will become so.

There is also another way to look at Peter's view.  Whitehead long ago
warned us that a complex question cannot be simplified by asking
simple questions about it.

John Gilmore, Ashland, MA 01721 -USA


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Help with elementary CPU speed question

[John Gilmore]

I have some sympathy with Peter Farley's 'rant'

Things should perhaps be otherwise.  They are not, and I see no
immediate prospect that they will become so.

There is also another way to look at Peter's view.  Whitehead long ago
warned us that a complex question cannot be simplified by asking
simple questions about it.

John Gilmore, Ashland, MA 01721 -USA

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Help with elementary CPU speed question

[Kirk Wolf]

Isn't the zPCR tool designed to help answer this kind of question?   I
would expect that you are better off hiring a consultant to do the
analysis if you don't have the expertise.   In the old days when I was
an IBM SE, we would do nearly all of this work for a customer who was
looking at a new machine from IBM.

Kirk Wolf
Dovetailed Technologies
http://dovetail.com

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Help with elementary CPU speed question

[Charles Mills]

> useful performance analysis requires years of experience with a platform,
its software, the use of 
> appropriate measurement software, and considerable statistical prowess

True enough, but it's like if your house was on fire. I could tell you that
firefighting takes specialized skills and years of experience. You'd still
want to pull out the fire extinguisher and do your best. I'm not trying to
take up a new consulting career; I am trying to answer one question, and I
am the only guy to do it.

I understand perfectly that CPU time is not everything, and typically has
little relationship to wall clock time. John, as you know better than most,
I have been in this racket *almost* as long as you have. But the question on
the table today is CPU time.

One more variable in here is that the 2094 is z/OS under VM -- I suspect
that may affect the precision of z/OS's reported CPU times.

Charles

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of John Gilmore
Sent: Tuesday, July 17, 2012 8:36 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Help with elementary CPU speed question

Rob Scott has pointed you in the right direction.

Worth emphasizing is that CP-SU ratios are most useful for botionally
'scientific' , CP-intensive applications.

Many 'business' applications are I/O-bound, some of them--MFUs are the
classic example--to the extent that shrinking CP processing to zero
has little measurable effect upon residence time.

In I/O bound situations CP-SU ratios may be irrelevant or, worse,
misleading.

This old distinction is often lost sight of here because mainframe
'scientific' processing does not figure much in our discussions.  It
remains important.

More generally, useful performance analysis requires years of
experience with a platform, its software, the use of appropriate
measurement software, and considerable statistical prowess.  Absent
this skill set, it is easy to make a fool of oneself and all but
impossible to make useful contributions.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Help with elementary CPU speed question

[Farley, Peter x23353]

 PMFJI here but this has become one of the most annoying and 
frustrating aspects of our business in the last decade or so.  It SHOULD NOT be 
necessary to have "considerable statistical prowess" or have access to DCOLLECT 
output (which most normal application programmers DO NOT HAVE) or to have 
access to a statistical package like MXG or any other such beast in order to 
answer simple questions like "does machine X have enough CPU horsepower to run 
YYY instances of program ZZZ at the same time?" or "how much CPU and elapsed 
time will the new changes in program ZZZ consume when moved into production?".  
These are questions that a normally skilled professional application programmer 
ought to be able to provide a reasonable answer to -- but we cannot, because 
"it depends...".

I'm not advocating a return to the single-non-pipelined CPU days of yore, just 
for SOMEONE (not me since I am obviously not qualified) to come up with a 
REPEATABLE way to measure a program's real performance with only one or two 
production-level test runs.  I should not have to waste my employer's scarce 
CPU resources to run a new or modified program ten or twenty times using 
production-quantity data volumes to get an "average" performance which turns 
out not to have ANY real relationship at all to the actual production 
performance.

Peter

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of John Gilmore
Sent: Tuesday, July 17, 2012 11:36 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Help with elementary CPU speed question

Rob Scott has pointed you in the right direction.

Worth emphasizing is that CP-SU ratios are most useful for botionally
'scientific' , CP-intensive applications.

Many 'business' applications are I/O-bound, some of them--MFUs are the
classic example--to the extent that shrinking CP processing to zero
has little measurable effect upon residence time.

In I/O bound situations CP-SU ratios may be irrelevant or, worse, misleading.

This old distinction is often lost sight of here because mainframe
'scientific' processing does not figure much in our discussions.  It
remains important.

More generally, useful performance analysis requires years of
experience with a platform, its software, the use of appropriate
measurement software, and considerable statistical prowess.  Absent
this skill set, it is easy to make a fool of oneself and all but
impossible to make useful contributions.
--


This message and any attachments are intended only for the use of the addressee 
and may contain information that is privileged and confidential. If the reader 
of the message is not the intended recipient or an authorized representative of 
the intended recipient, you are hereby notified that any dissemination of this 
communication is strictly prohibited. If you have received this communication 
in error, please notify us immediately by e-mail and delete the message and any 
attachments from your system.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Help with elementary CPU speed question

[Charles Mills]

Lizette, thanks, you're always helpful. Answers in line below.

Charles

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Lizette Koehler
Sent: Tuesday, July 17, 2012 7:59 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Help with elementary CPU speed question

> If you have access to the MXG software, search in SOURCLIB for this
information.  Dr. Merrill's book which is in this library can be very
helpful.

I don't have MXG. I have the IBM performance tables
https://www-304.ibm.com/servers/resourcelink/lib03060.nsf/pages/srmindex.
That's where I got the SU/second numbers in my OP. My question really was
whether the SU/Second machine-to-machine ratio was the first factor to be
looking at, and was I using them correctly, and I guess that is so because
no one has said it is not. (It's just that beyond that, "it depends.")

> Second, what is meant by CPU Performance question?

The question distilled to its essence is "if job X takes n CPU seconds on
box A, then will box B have enough horsepower to run 1000 jobs very much
like X every day, and how much CPU time will they use?"

> There is not, imho, not a one answer to a general question.  It will
depend on hardware, software and user perception.

Yup. But management wants (IMHO understandably) a go or no-go answer.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Help with elementary CPU speed question

[John Gilmore]

Rob Scott has pointed you in the right direction.

Worth emphasizing is that CP-SU ratios are most useful for botionally
'scientific' , CP-intensive applications.

Many 'business' applications are I/O-bound, some of them--MFUs are the
classic example--to the extent that shrinking CP processing to zero
has little measurable effect upon residence time.

In I/O bound situations CP-SU ratios may be irrelevant or, worse, misleading.

This old distinction is often lost sight of here because mainframe
'scientific' processing does not figure much in our discussions.  It
remains important.

More generally, useful performance analysis requires years of
experience with a platform, its software, the use of appropriate
measurement software, and considerable statistical prowess.  Absent
this skill set, it is easy to make a fool of oneself and all but
impossible to make useful contributions.

John Gilmore, Ashland, MA 01721 - USA

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Help with elementary CPU speed question

[Lizette Koehler]

> 
> I have gotten dragged into a CPU performance question; a field I know
little about.
> 
> 
> 
> I run a test on a 2094-722. It is rated at 19778 SU/Second. The job
consumes
> .146 CPU seconds total.
> 
> 
> 
> I run the same job on a 2064-2C3. It is rated at 13378 SU/Second. All
other things
> being roughly equal, should I expect that the job will consume 1.48
> (19778/13378) times as much CPU time, or .216 CPU seconds?
> 
> 
> 
> Is my logic right, or am I off somewhere? I'm not worried about a
millisecond or two;
> just the broad strokes.
>


If you have access to the MXG software, search in SOURCLIB for this
information.  Dr. Merrill's book which is in this library can be very
helpful.

Second, what is meant by CPU Performance question?

There are many answers depending on the question the question is asked.

There is not, imho, not a one answer to a general question.  It will depend
on hardware, software and user perception.

Lizette

> 
> 

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Help with elementary CPU speed question

[Rob Scott]

Charles 

How many "It depends.." answers do you want? :-)

If all the program does is increment a register in a tight loop then I would 
imagine that your assumption would be roughly OK. If it does anything more 
"complicated" (eg open a dataset, maybe call a system routine, DB2 subsystem, 
XCF service, attach a subtask, etc etc), then there are so many things can 
affect it.

Rob Scott
Lead Developer
Rocket Software
77 Fourth Avenue . Suite 100 . Waltham . MA 02451-1468 . USA
Tel: +1.781.684.2305
Email: rsc...@rs.com
Web: www.rocketsoftware.com


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Charles Mills
Sent: 17 July 2012 14:53
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Help with elementary CPU speed question

I have gotten dragged into a CPU performance question; a field I know little 
about.

 

I run a test on a 2094-722. It is rated at 19778 SU/Second. The job consumes
.146 CPU seconds total.

 

I run the same job on a 2064-2C3. It is rated at 13378 SU/Second. All other 
things being roughly equal, should I expect that the job will consume 1.48
(19778/13378) times as much CPU time, or .216 CPU seconds?

 

Is my logic right, or am I off somewhere? I'm not worried about a millisecond 
or two; just the broad strokes.

 

Thanks,

Charles 


--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN