Regarding the PR/SM time slice discussion, please review the Global Reset
Profile Definitions section of the PR/SM Planning Guide. PR/SM does
indeed operate on a time slice basis, where the time slice is the length of
time that a logical processor can be assigned to a physical
processor. This time slice concept applies to all models including z196
(not just old models as one poster believes). The PR/SM time slice basis
normally is used for dispatching most logical processors, and is used
almost exclusively for logical processors that are very busy. PR/SM also
operates on an interrupt basis, but the interrupt basis is used primarily
for reordering waiting-for-dispatch logical processors on the PR/SM Logical
Processor Ready Queue.
There can be a default time slice, or a user-defined time slice. In either
case, the time slice applies to all logical processors in all active LPARs
(except for shared LPARs using HiperDispatch). If a logical processor
operating in its time slice on a physical processor has not voluntarily
relinquished the physical processor by entering a Wait State, PR/SM can
"intercept" the logical processor when its dispatch time slice expires.
The default time slice is computed by PR/SM for each LPAR, using the algorithm:
| (25 milliseconds * number of shared physical
processors) /
| (number of logical processors not in stopped state defined for all LPARs
with shared logical processors)
There is an arbitrary minimum computed default time slice value of 12.5
milliseconds and a maximum computed value of 100 milliseconds.
The user-specified time slice can be defined by the user clicking "Defined
by User" and specifying a value from 1100 milliseconds in the Processor
Running Time section of the Options Page, Reset Profile.
Note that for shared LPARs using HiperDispatch, the assigned dispatch time
slice for High Polarity logical processors to physical processor is 100
milliseconds, regardless of whether the processor time slice is computed by
PR/SM or specified by a user.
Regarding the concept that PR/SM weights are enforced only when there is
processor constraint, this concept regrettably is mentioned in many
presentations (often by IBM presenters). The impression left is that
unless your processors are always very busy and constrained, PR/SM does not
enforce the weights. There are two issues to consider:
1. Analysts often look at an RMF or other report, see 50% busy (or so),
and conclude that PR/SM in their environment does not enforce weights
because their processors are only 50% Busy and there is no
constraint. What is left out of the discussion is that processors almost
always are constrained at some time regardless of the average processor
busy percent. For that matter, if you get down to microsecond levels, you
might have 100% busy for a large number of cycles and then 0% busy for an
equal number of cycles, with the result being 50%. The same concept likely
applies in most systems when moving up to a per-millisecond level, or even
moving to a per-second level. That is, a processor reverts between 0%
busy and 100% busy and the observed Average Percent Busy differs depending
on the interval of lapsed time in which the percent busy is computed and
reported. It is easy to visualize that there is much more variability in
average processor busy when examined at a per-second basis than when
examined at a per-hour basis.
As earlier mentioned, the time slice used by PR/SM normally ranges from
12.5 milliseconds to 100 milliseconds. This leads to the concept that
PR/SM does enforce weights at intervals when processors are very busy, and
these intervals may be substantially smaller than the average processor
busy as reported by RMF or other reporting tools.
2. While PR/SM might not enforce weights when processors are not busy at
small time intervals, the weights can have an impact. This is because
PR/SM maintains a Logical Processor Ready Queue of logical processors
awaiting dispatch to a physical processor. This Queue is ordered based on
how much of its assigned weight each logical processor on the queue has
used. Logical processors with less use relative to weight are placed ahead
of logical processors with more use relative to weight. It is unlikely
that this effect would harm performance on a continual basis, but could
cause periodic delays that might be reflected in service class periods with
short response goals. This is one of the many factors that can cause
periodic "spikes" of poor performance in such service class periods.
Regards,
Don
******
Don Deese, Computer Management Sciences, Inc.
Voice: (804) 776-7109 Fax: (804) 776-7139
http://www.cpexpert.org
******
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
