On Tue, 13 May 2008 05:43:24 +, Ted MacNEIL [EMAIL PROTECTED] wrote:
I think you have some terminology problems.
CF LPARs are NOT dummies.
If you are truly using them as CFs, they should not be used in this manner.
It is OK
What he means , is , he does not need any CF , but he wants to
G'day Michael - this is an ugly hack. But you knew that already.
Weights being merely guess-timates, I normally set them (for all LPARs) to
what you want the box divvied up as when all LPARs are (concurrently) 100%
busy. In your case, maybe set the CF LPAR to slightly higher, just for
sanity -
Thanks Bruno Shane. I know this is not pretty, but you give me more
confidence in what I hope will be a short term solution.
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED]
We wish to follow the advice given in an earlier to cap MSU usage of our 2
LPARs (2 monoplexes) by intoducing a dummy CF LPAR when we upgrade our
z890. I understand we should SET DYNDISP OFF.
But what would be a good weight for the CF LPAR so it always consume a
fixed number of MSUs (capped of
But what would be a good weight for the CF LPAR so it always consume a fixed
number of MSUs (capped of course).
CF's do not contribute to MSU charging.
They should always be allowed to run without any form of capping or sharing.
What problem are you trying to solve?
-
Too busy driving to stop
But what would be a good weight for the CF LPAR so it always consume a
fixed number of MSUs (capped of course).
CF's do not contribute to MSU charging.
They should always be allowed to run without any form of capping or
sharing.
What problem are you trying to solve?
Upgrading capacity of z890
Upgrading capacity of z890 but capping total MSUs of existing 2 LPARs to 26
MSUs, but also not wanting to cap each LPAR as such (i.e. each LPAR could
get the whole 26 MSUs if the other LPAR is idle). Therefore using the dummy CF
LPAR to consume the MSUs we do not want to be charged for.
I
On Sun, 1 Jan 2006 10:30:35 +1000, ibm-main [EMAIL PROTECTED] wrote:
Seems you are trying to use for the wrong reason.
Why don't weightings fulfil your requirements - especially if you are
prepared to use the whole box ???.
Soft capping is a *financial* contortion, not a technical aid to solving
Lately I am seeing a very large difference between the LPAR BUSY TIME PERC
and the MVS BUSY TIME PERC fields in the RMF CPU Activity report. The
difference is over 20% at peak hours. This was not the case before I started
using CF capping.
The CF LPAR used to guard MSUs has the highest weight on
You're right Ted. In fact, I really dont want to share CPs with the CF.
However, the current soft-papping mechanism only allows to soft-cap an LPAR
to a certain amount of MSUs.
At first I used soft-cap. Then I noticed we encounter situations where one
LPAR is being soft-capped, while all the
From: Gil Peleg
At first I used soft-cap. Then I noticed we encounter situations where one
LPAR is being soft-capped, while all the others are not even close to
their
defined capacity. From my point of view, this is a poor allocation of
resources (which we are paying for). Obviously, If the
Ted,
That's not quite right. RMF CPU busy is 1-(waittime/interval). There is no
MVS Busy field: it is actually CPU Wait Time that gets accumulated and CPU
busy is calculated from Wait Time.
If a Logical Instruction Processor (LIP) is pre-empted, then it is not in a
wait state and there is no
CF doesn't *always* take 100% of CPU power. It depends. 100% is taken
when only dedicated processors are assigned to CF LPAR. There is a
feature called Dynamic CF Dispatching (DCFD), which changes CF behavior
on shared engines. In some cases you can switch DCFD off using DYNDISP
command.
On Fri, 30 Dec 2005 18:46:24 +0200, Gil Peleg [EMAIL PROTECTED] wrote:
Lately I am seeing a very large difference between the LPAR BUSY TIME PERC
and the MVS BUSY TIME PERC fields in the RMF CPU Activity report. The
difference is over 20% at peak hours. This was not the case before I started
Rick Ralston of Humana presented a CMG paper titled zSeries, Sub-Capacity
Workload License Charges, Soft-Caps, and WLM which has some good
information on LPAR capping. And if you are concerned with monitoring LPAR
capacity and possibly considering workload-based charging (WLC), Al
Sherkow's LCS
On Thu, 29 Dec 2005 01:24:40 +0100, R.S. [EMAIL PROTECTED] wrote:
Ooops! The only thing I forgot is you have *ONE* LPAR. Any number you
provide to the LPAR will give 100%... Well...
Maybe you have to add another LPAR. AFAIK it can be done dynamically,
but not on z/800.
BTW: Depending on your
Hi,
We just went to LPAR mode from basic mode. We have a 2066-002 (z800)
that is about 350 MIPS. We currently only have a single LPAR, but we
wish to CAP the LPAR at 200 MIPS. (for ISV charging purposes)
Is this easy to do? How? Can it be done without a POR or IPL?
Thanks for any help!
] On
Behalf Of Martin, Mike
Sent: Wednesday, December 28, 2005 2:48 PM
To: IBM-MAIN@BAMA.UA.EDU
Subject: LPAR Capping
Hi,
We just went to LPAR mode from basic mode. We have a 2066-002 (z800)
that is about 350 MIPS. We currently only have a single LPAR, but we
wish to CAP the LPAR at 200 MIPS. (for ISV
Martin, Mike wrote:
Hi,
We just went to LPAR mode from basic mode. We have a 2066-002 (z800)
that is about 350 MIPS. We currently only have a single LPAR, but we
wish to CAP the LPAR at 200 MIPS. (for ISV charging purposes)
Is this easy to do? How? Can it be done without a POR or IPL?
19 matches
Mail list logo
