Re: Auto Tuning -- MIDRANGE-L

Trevor, I don't know about what is really the truth these days - too many IBM docs get outdated very quiclky. But this one referred to the RISC version of SS1, so it'd be after any F70, right?

The odd thing to me is that no job runs longer than the internal time slice, but the activity level is held for it until the end of its external time slice value, or a long wait.

I think that activity levels should not be so low as before - that count includes any threads started on behalf of "real" jobs, so it needs to be higher in some cases. I assume that having transition rates of W-I as 10% of A-W on a busy system is still desirable? (I may be wrong on the details here - check the Work Mgmt book)

Just thinking - not enough to do. NOT!

Vern

At 01:00 PM 2/3/2004 -0600, you wrote:

Summary:
1) Keep timeslices small
2) Keep pool activity levels low
3) Internal timeslice does not matter - since you can't change it anyway

The interesting part about this is that the IBM documentation refers to
timeslices as low as 200ms, but ships them at 2000ms and 5000ms.. And the
number one "fudge" to getting more throughput is still to increase
timeslice!

I do know that when I last taught about the internal time slice, it had been
reduced from 500ms to 250ms - this was for the F70. I doubt it is back up to
500ms for the current crop of processors..

----- Original Message -----
From: "Vern Hamberg"
Subject: Re: Auto Tuning


> The following is from an article in the Registered Knowledge Base -t ake
it
> for what it's worth. It says it's for all releases of OS/400 (5763, 5769,
> 5722) so I guess that's all RISC boxes.
> :
> >The system has an Internal Time Slice of 500ms (milliseconds). If the
time
> >slice for a job is set to greater than 500ms, the system gives peer jobs
> >of equal priority a chance to run.
> >
> >For example, sbs=Subsystem, AL=Activity Level, TS=Time Slice in ms.
> >
> >1 sbs BATCH1 AL=1 JobA TS=200
> >sbs BATCH2 AL=1 JobB TS=200
> >Processor runs each for 200ms and AL swaps equally.
> >2 sbs BATCH1 AL=1 JobA TS=200
> >sbs BATCH2 AL=1 JobB TS=2000
> >Processor trades jobs at 200ms and 500ms respectively.
> >3 sbs BATCH1 AL=1 JobA TS=500
> >sbs BATCH2 AL=2 JobB & JobC TS=200
> >
> >- When JobA TS ends after 500ms, because it is the only job in the AL,
> >processor handles it again after TS ends for
> >jobs B & C.
> >
> >- If TS for JobB and JobC were 200ms, JobA would be handled again by the
> >processor after running JobA for 200ms and JobB for 200ms, then JobA
would
> >run for 500ms.
> >
> >- If the AL is set to greater than 500ms, the AL is held for that job
> >after the processor tends to JobB and JobC for their respective TS
limits.
> >This means that after the internal TS limit is reached, the job does not
> >lose its AL until its real TS is ended (assuming no Long Waits).
> >
> >- Therefore, it is the AL that is more important than the TS in
> >determining the effect of increasing the TS for a job and its affect on
> >jobs in other or the same subsystem. Increasing the TS affects other jobs
> >in the system to a minor extent only, because there is an internal 500ms
> >limit. Adding more AL to a subsystem (with jobs to fill the levels)
> >affects processor time for a job more than the increase of TS.
>

_______________________________________________
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.