RE: CPU utilization, Priority, and Throughput

Yes.  No.  Please see my reply to Nigel.  FYI, the internal time slice isn't
fixed at 500 mills, it varies by CPU.  This is not important, just a
curiosity.

Richard Jackson
mailto:richardjackson@richardjackson.net
www.richardjacksonltd.com
Voice: 1 (303) 808-8058
Fax:   1 (303) 663-4325

-----Original Message-----
From: owner-midrange-l@midrange.com
[mailto:owner-midrange-l@midrange.com]On Behalf Of Bull, Jeff
Sent: Tuesday, July 18, 2000 3:43 AM
To: 'MIDRANGE-L@midrange.com'
Subject: RE: CPU utilization, Priority, and Throughput


On a recent 'performance' course at IBM we were told that regardless of the
TIMESLICE setting, an 'internal timeslice' of 500ms (not changeable) should
prevent this kind of CPU-bound, low-priority job from dominating.

Jeff Bull

-----Original Message-----
From: watern@cbs.fiserv.com [mailto:watern@cbs.fiserv.com]
Sent: Tuesday, July 18, 2000 9:42 AM
To: MIDRANGE-L@midrange.com
Subject: Re: CPU utilization, Priority, and Throughput






Richard Jackson wrote ......
>For reasons that I suspect but cannot prove, it seems to me that an AS/400
>job running at priority 99 can interfere with jobs running at higher
>priorities.

Richard,

This may not be applicable to your situation, but one scenario where this
may
happen is if the low priority job has a longer timeslice than the high
priority
jobs and the low priority job is cpu-bound. (dont know if that is the right
term?). This means that when the low priority job gets its slot, it keeps it
for
the maximum time it can. If the timeslice is relatively large, the effect
can be
noticeable.

Often, low priority jobs have longer timeslices than high priority jobs, so
although low priority jobs dont get CPU time as often,  when they do get it
they
get a bigger slice. (For example Interactive jobs may have priority 20,
timeslice 1000ms whereas batch jobs have priority 50, timeslice 5000ms).

When a job encounters a wait (eg for file i/o) it will give up its CPU time.
The "traditional" batch job (if there is such a thing any more) on the AS400
is
likely to contain file processing and so will often give ups its CPU slot
before
the full timeslice is used.  The same is often true of interactive jobs.
However
if there is a batch  job running which is processor-intensive (eg lots of
calculations with data already loaded in memory), then it will grab the CPU
and
use its full timeslice every time it becomes available to it.  This means
that
when other jobs request CPU time they will more often than not have to wait
for
it.

Priroity is only important when the CPU timeslice is completed for one job
and
the system allocates who gets the next slice. Once a job has got CPU time,
it
has it until either the timeslice is complete or it encounters a wait
condition,
in which case it gives it up.

The above is based upon my understanding of work management on the AS400
from a
few years ago. It may have changed in the meantime, but I would be surprised
if
general principles of priority and timeslices did not still apply.

I have come across this situation once before. It was solved by getting the
job
to reduce its own timeslice once it had completed file i/o.  The application
involved route planning: after loading information about a group of
locations,
the system attempted to calculate the most efficient routing between them -
this
bit was mostly comparing different permutations of locations within routes,
so
was very processor intensive.

Rgds,
Nigel


+---
| This is the Midrange System Mailing List!
| To submit a new message, send your mail to MIDRANGE-L@midrange.com.
| To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com.
| To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator:
david@midrange.com
+---
+---
| This is the Midrange System Mailing List!
| To submit a new message, send your mail to MIDRANGE-L@midrange.com.
| To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com.
| To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator:
david@midrange.com
+---

+---
| This is the Midrange System Mailing List!
| To submit a new message, send your mail to MIDRANGE-L@midrange.com.
| To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com.
| To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---