RE: CPU utilization, Priority, and Throughput

Nigel:

Thanks for your comments.  My experience matches your description but I sat
in a meeting in the JDE offices in Denver Colorado in February of 1999 with
a system architect from IBM Rochester and he kept shaking his head no and
saying that it didn't work that way.  According to others, that gentleman is
in a position to know how it works.

For what it is worth, your description perfectly matches the behavior of the
MVS dispatcher.  It is only invoked when a task leaves the CPU for some kind
of wait - either a wait generated by its own behavior (like an IO) or by
some kind of time-slice mechanism.  We all know that MVS contributed some
behaviors to the ancestors of the AS/400.

Several years ago in a private conversation, Mr. Rick Turner, an AS/400
performance person of some repute, indicated that IO was helpful to regulate
the flow of work through the system.

One segment of the JDE OneWorld application has a problem when running on
AS/400.  That segment called UBE (universal batch engine) uses a large
run-time interpreter.  UBE jobs may sit in the CPU for many seconds without
doing any physical IO.  While using SMTRACE to work on a problem in Finland
last winter, I just happened to notice a UBE that ran continuously for one
full time slice interval (5 seconds) without any interruptions except the
PCO event.  If I run some number of UBE jobs equal to or greater than the
number of CPUs in an AS/400, higher-priority interactive slows way down -
the UBEs kill the system.  I proved that at a customer in Omaha NB in 1998.
They had an 8-way and when they ran 7 concurrent UBEs on it, everything was
fine.  When they changed to 8 concurrent UBEs, interactive response time
went from about 5 seconds to between 30 seconds and a minute.  Based on that
result, I created a guideline that the number of concurrent UBEs should
equal number of CPUs minus one.  This caused some mirth with the technical
consultants who had customers with single-CPU machines but the evidence was
clear.  Based on some significant work done in Oxford UK in 1998 by Mr. Alan
Wallet and Ms. Debbie Hatt, a  workaround recommendation arose for the "UBEs
hog the CPU" problem - change the time slice to 200 milliseconds.  It helps
but it isn't a cure.

Returning to February 1999, the system architect mentioned above indicated
that the AS/400 dispatcher is truly preemptive - a job running in a CPU will
be preempted if higher priority job arrives and that interruptions are
possible at MI boundaries or a few other places in long-running instructions
(create index peeks around every few seconds to see if someone else wants a
CPU, that sort of thing).  Of course, this doesn't jive with my experience
and it doesn't seem to jive with your route planning experience either.  But
general purpose computers aren't supposed to run programs that perform no
IO.

It is the conflict between what I have observed and what I have been told by
the system architect that concerns me.  I want to find other people with the
same issue then go back and ask my acquaintance if I misunderstood what he
said.  If I didn't misunderstand, can he help us to understand what causes
these strange behaviors.  Before I can ask for assistance, I have to have
some good reproducible examples.  That is the motivation for my question.

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 watern@cbs.fiserv.com
Sent: Tuesday, July 18, 2000 2: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
+---