Re: Auto Tuning

Hi Mark, Trevor,

Yes you're right, there is an internal timeslice, but the external timeslice
is still important, and reducing it does seem to improve throughput!
As I understand it, the internal timeslice is model dependent (or CPU
dependent), and influences how long a job waits for CPU - so the wait time
is the average Queue length times the internal timeslice.
The (external) timeslice is related to the activity level. How long does the
new arrival have to wait for the job to leave the activity level? Average is
half the service time - so if it is 2 seconds, then the average wait is 1
second.
Using the estimate of active work stations (AWS) on the transaction report
you can draw a graph for a particular system to show the number of jobs in
the activity level. Usually there is a big bulge at the beginning, then it
tails off (depending on the application). This means that usually there are
only x jobs in the activity level, but sometimes there are more. To estimate
a good timeslice for this system/workload, use 3 x average CPU per
Transaction (on the System Report). This will be around the point on your
graph where it tails off. You also need to set the activity level
accordingly. Set these values together - it isn't true, as people often like
to say, that you should only change one thing at a time! Many things work
together.
But having said all that, who knows, next version of OS/400 could be
completey changed. You always have to be on the lookout for things that you
thought worked and now they don't (like counting faults in the pools!)
Anyway, performance tuning is a great subject, and a black art. Have fun,

cheers,

Clare

----- Original Message -----
From: "trevor perry" <trevorp@xxxxxxxxxxxxxxxx>
To: "Midrange Systems Technical Discussion" <midrange-l@xxxxxxxxxxxx>
Sent: Tuesday, February 03, 2004 4:07 PM
Subject: Re: Auto Tuning


> Mark,
>
> There has always been an internal timeslice - this is the ~trick~ that
> allows the box to appear as though it is multi-tasking. Certainly, this
> internal timeslice has reduced drastically with new hardware, and of
course,
> with multiple processors there must be multiple internal timeslices.
>
> However, the internal timeslice has never been a parameter that could be
> used for tuning. It was never able to be changed, and still cannot be
> changed. And, it has nothing to do with the external timeslice which is a
> parameter for each job. And, the external timeslice is not used to assign
an
> actual machine timeslice at the level of the MI task.
>
> I would be surprised if the algorithm has changed to ignore the external
> timeslice. I would not be surprised if this is another piece of
> misinterpreted information passed on as fact - that seems to be how most
> tuning stories go... Still, if you can find a source for this, I would
> welcome the education.
>
> Trevor
>
> ----- Original Message -----
> From: "Mark S. Waterbury"
> Subject: Re: Auto Tuning
>
>
> > Hello, all:
> >
> > With all the talk of "tuning" OS/400, I seem to recall, back when IBM
> first
> > introduced the RISC-based AS/400s, there were major internal changes
> > "under the hood" due to the fact that the RISC PowerPC processors were
> > so much faster than the IMPI CISC processors.
> >
> > I seem to recall that someone (perhaps an IBMer) told me that those
> > values specified for the "timeslice" no longer directly affect the
> internal
> > timeslice used by the RISC processors. The machines are so much faster,
> > and the PowerPC processes so many more instructions per second, that
> > IBM decided to "ignore" that parameter, or only uses it as a "guideline"
> > of some sort... internally they use a much, much smaller timeslice...
> >
> > Especially now that OS/400 supports threads and multi-threading within
> > a single job/process.
> >
> > In other words, the external job level values you specify for timeslice
> etc.
> > no longer directly influence how SLIC assigns the actual machine "time
> > slice" at the level of the MI task.
> >
> > (I am not sure what those system values really do any more.)
> >
> > Hope that helps...
> >
> > Mark S. Waterbury
>
> _______________________________________________
> This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
list
> To post a message email: MIDRANGE-L@xxxxxxxxxxxx
> To subscribe, unsubscribe, or change list options,
> visit: http://lists.midrange.com/mailman/listinfo/midrange-l
> or email: MIDRANGE-L-request@xxxxxxxxxxxx
> Before posting, please take a moment to review the archives
> at http://archive.midrange.com/midrange-l.
>