× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



Leif,

I think that there is still value in your broad assertion.  I think if
you were to move your experiment as described to newer hardware, it
would behave as it does on your 'old, feeble machine'.  The only
difference, if I understand the documentation, is that the imposition of
CFINT might lag a little longer.

IBM describes themselves as working at the margins so that users can
come closer to the limit without incurring a penalty and so that
transitory spikes over the limit will likewise not trash the system.
Your experiment, (or Chris' system as described in his initial post),
should end up with the system lying on its back with its legs up in the
air, quivering.

Regards,
Andy

> On Behalf Of Leif Svalgaard
> Subject: Re: Interactive Feature Upgrade Theory
>
> From: Andy Nolen-Parkhouse <aparkhouse@attbi.com>
> > I went back to my documentation to try and figure out why I would
have
> > made such an assertion
>
> Thanks Andy for the clarification. Part of the resolution of this
> "problem" may lie in different hardware. I only have an old, feeble
> machine and should keep that in mind when making sweeping
> generalizations. My assertion (in retrospect, maybe a bit too strong)
> was based on the following experiment:
>
> 1) make a batch program B that does:
>      Again: go to Again;
> 2) make an interactive program A that does:
>     Again: count to 1 billion (or some such number);
>                show a screen (any screen);
>                go to Again;
> 3) submit B to batch (e.g. to QSYSNOMAX) and set its priority to 20
> (same as interactive). Use WRKSYSACT or WRKACTJOB
> to verify that B gets almost 100% of the CPU time.
> 4) start A in an interactive session.
> Use WRJSYSACT or WRKACTJOB to verify that now B gets 50%
> and A gets 50%.
> 5) wait (on my system about a minute) until CFINT kicks in. On my
> system I can run 40% interactive, so one would expect that when
> CFINT kicks in (if the new algorithm worked), the system would limit
> program A to 40% and give 60% to program B. This is not what
> happens. Instead, CFINT takes 60% and the two programs B and
> A share the remaining 40% evenly with 20% each.
> It would be interesting to see what the result would be on one of
> the models that claim the "new algorithm".
> BTW: sometimes CFINT does not kick in until I start yet another
> interactive session. For the best test start two batch jobs with B
> and two interactive jobs with A. Then the above holds, if one
> counts the two Bs as one, and the two As as one.




As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.