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



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


As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
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.