Represent the capacity of each CEC in 'SU's'. Perhaps with a reference
line for the "base" configuration.
IMO, the base configuration would be:
N = # of Physical CPs
Rate - Capacity rating (per engine). E.G. xxxx-Y02 has less capacity
that xxxx-Z02. Relative processor ratios are available from a number of
sources
(Cheryl Watson, IBM/LSPR, Gartner......). Choose your favorite.
Generally these tables will have available MSUs as one of the entries.
SUCONVERSION - As documented in SMF/RMF manuals.
e.g. Baseline N*Y02*SUCONVERSION (reference line)
update N*Z02*SUCONVERSION (new capacity/reference line)
HTH,
<snip>
'Capacity Management' in this installation is done by manually varying
logical cps on- and offline at predetermined times and by shifting lpar
weights when someone complains. Who gets more mostly depends on who
complains loudest. 'Capacity Planning'? What's that?
Back in March when Fukushima blew up and the above methods were not
sufficient to meet the deadlines, for the first time we employed CoD.
First we got one more physical cp (which I think was enough to meet the
deadlines), but management did another CoD going to not-slowed-down cps,
and adding one more. For 24 hours we had almost double of our usual
capacity (with the accompanying bills from the software vendors). At
that point management wanted to *see* when we had added the physical cp,
which of course is impossible when the usage values are normalized to
100%. 100% wasn't equal to 100% anymore, as the underlying reference had
changed. Nobody else had an idea how to graphically present that, so I
came up with the idea of using cpu seconds consumed. *Then* management
wanted to know how much more than our regular capacity we had needed. I
am sure once I show them any new grafic they will ask some new question
that cannot be answered from what we have. And asking them to tell !
me *beforehand* what they need is also asking too much. I am usually
expected to read minds. <rant off>
With the 'capacity per engine' approach I can represent more cps. I
don't think that would show if a cp doesn't run slowed down anymore. At
that point in one cpu second 'more' can be done, so 1s is not equal to
1s anymore. And that is only the view of the whole box. I also have the
added question how much 'capacity' is available per lpar. Currently all
I see is a 100% percent value that assumes that all logical cps will
always immediately run on a physical cp. (And logical-to-physical ratio
is way beyond any recommendation). So 100% cannot be achieved. But where
to draw the line?
It is going to get worse on the new box. We will have fewer physical
cps. We also have at least one more lpar than physical cps per box. On
one box we have x physical cps, and two lpars with all x logical cps.
Plus some more lpars with fewer logical cps. IBM wanted us to use
Hiperdispatch, and I vehemently objected. Given my notoriety, IBM
eventually agreed that Hiperdispatch will be a bad idea here. :-)
I will mull this over some more. I might have to go the service unit
approach, but only if that will also solve the question how much
capacity can be achieved on any one lpar that is overspecifed (dare I
call it 'misconfigured'?) the way it is. Any thoughts are welcome. :-)
</snip>
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
