RE: Interactive Feature Upgrade Theory

["Andy Nolen-Parkhouse" <aparkhouse@xxxxxxxxx>]

This is a multi-part message in MIME format.
--
[ Picked text/plain from multipart/alternative ]
Leif,



I went back to my documentation to try and figure out why I would have
made such an assertion.  The text below is from the V5R1 Performance
Capabilities Reference (referring to changes in V4R5).  As I re-read it,
it confirms that IBM is trying to do what I described; minimize the
impact of CFINT on other jobs.  While they're not clear on the gory
details, it seems that they are not changing the behavior of CFINT, but
rather trying to control the circumstances which trigger CFINT.  They
are not particularly clear, but as I understand what they've written,
the work is being done at the margins.  They may have successfully
minimized the impact of transitory interactive spikes.  Consistently
exceeding the limit over a period of time will call in the hounds and
trash the system, which confirms your point.



Regards,

Andy Nolen-Parkhouse



<quote>



2.2.1 New in V4R5

In V4R5 there are several new 2xx, 8xx and SBx model servers. These new
servers models utilize an enhanced server algorithm that manages the
interactive CPU utilization. This enhanced server algorithm may provide
significant user benefit. On prior models, when interactive users exceed
the interactive CPW capacity of a system, additional CPU usage visible
in one or more CFINT tasks, reduces system capacity for all users
including client/server. New in V4R5, the system attempts to hold
interactive CPU utilization below the threshold where CFINT CPU usage
begins to increase. Only in extreme cases, where interactive demand
exceeds the limitations of the interactive capacity for an extended time
(usually from long-running, CPU-intensive transactions), will overhead
be visible via the CFINT tasks.  Highlights of this new algorithm
include the following:



As interactive users exceed the installed interactive CPW capacity, the
response times of those applications may significantly lengthen and the
system will attempt to manage these interactive excesses below a level
where CFINT CPU usage begins to increase. Generally, increased CFINT may
still occur but only for brief transient periods of time. Therefore,
there should be remaining system capacity available for non-interactive
users of the system even though the interactive capacity has been
exceeded. It is still a good practice to keep interactive system use
below the system interactive CPW threshold to avoid long interactive
response times.



Client/server users should be able to utilize most of the remaining
system capacity even though the interactive users have temporarily
exceeded the maximum interactive CPW capacity.



<snip>



With the advent of the new server algorithm, there is not a concept
known as the interactive knee or interactive cap. The system just
attempts to manage the interactive CPU utilization to the level of the
interactive CPW capacity.



<snip>



The new server algorithm only applies to the new hardware available in
V4R5 (2xx, 8xx and SBx models).  The behavior of all other hardware,
such as the 7xx models is unchanged.



</quote>



> On Behalf Of Leif Svalgaard

> Subject: Re: Interactive Feature Upgrade Theory

>

> From: Andy Nolen-Parkhouse <aparkhouse@attbi.com>

> > My point had to do with IBM's implementation of the interactive

> > governor.  In its first appearance, CFINT would trash the entire
system

> > when you exceeded the threshold.  This affected both interactive and

> > non-interactive jobs.  As time has passed, they have attempted to
limit

> > interactive work to the agreed-upon CPW threshold while still
allowing

> > batch work to proceed without as great an effect.  That's been their

> > stated goal, and they say they've improved.  How well, I don't know.

> >

>

> This is easy to check. The result is that it is NOT true that batch is

> not affected (at least not through V5R1 - don't know  about V5R2).

> Also, from the description of how CFINT-punishment works, it is clear

> that every job is affected the same way.

--