Re: Timeslices -- MIDRANGE-L

Michael is right - if your system is oversized then no problem, however if
your system is at all heavily loaded or overloaded, then timeslice (and the
other constructs) can be very important. Try it and see. AS/400s are shipped
with a timeslice of 2000 (2 secs) in QINTER, however unless you still have a
B10 this makes no sense. The faster your CPU, the lower the timeslice should
be. (300 is common.)
To calculate it, take the average CPU per Transaction (you can find this on
the Performance Tools system report), and multiply by 3. This should ensure
that 90% transactions don't have to wait. See how the jobs fly now!
Of course, you also need to decide whether or not to use the Dynamic
Priority Scheduler - if you have an application where jobs may 'hog' a
higher priority (such as BPCS) this works well, but some combinations of
batch/interactive and 'server' systems may require this to be off. (there
are 2 systems values that work together)
For the activity level setting, again lower is usually better, but again you
can calculate the optimum value from Performance Tools data, using the
QTRTSUM file and looking at the number of jobs that were in the activity
level and the number that went ineligible. The way to do this is to plot a
graph of these figures, and pick a number at the end of the curve. Think of
coffee machines or delicatessan counters - service time by arrival rate,
doubled, ensures that 90% of arrivals don't have to wait. A quicker way is
to simply lower it until you see jos going ineligible, then raise it
slightly.
Of course, the 'purge (maybe)' concept may still apply (i.e. the system
doesn't always do what you tell it) - there is an internal timeslice too.
And we know that Purge (and the PAG) have now gone, so who knows what will
go next???
Hope this helps,
Clare

Clare Holtham
IBM Certified AS/400 Systems Administrator
E-Mail: Clare.Holtham@btinternet.com
Mobile: +44 (0)7960 665958
----- Original Message -----
From: "Michael Oakes" <Michael.Oakes@eb.uk.com>
To: <midrange-l@midrange.com>
Sent: Thursday, August 30, 2001 1:30 AM
Subject: RE: Timeslices


> It also depends on the amount of work the system is doing. If it is
heavily
> utilised the timeslice and run priority count very much. I would consider
> myself lucky that I had the same run times for jobs!
>
> -----Original Message-----
> From: srichter [mailto:srichter@mail.autocoder.com]
> Sent: 30 August 2001 01:24
> To: midrange-l@midrange.com
> Subject: Re: Timeslices
>
>
> Hey Leif,
>
> I dont think timeslice matters any more.
>
> I work on a very fast 720 that uses the default qinter timeslice of 2000.
> 2000 milliseconds back in the s38 days meant something.  Now, you can
> probably run many batch jobs with 2 seconds of cpu time.
>
> I am thinking of saying that activity level matters more than timeslice,
> that it might be too low and jobs that want to run have to wait to get
into
> the activity level. But jobs run so much faster now, that they leave enter
> and leave the activity level so fast that the actual activity level never
> gets very high and jobs are never waiting to get into it.
>
> Steve Richter
>
>
> ---------- Original Message ----------------------------------
> From: "Leif Svalgaard" <leif@leif.org>
> Reply-To: midrange-l@midrange.com
> Date: Wed, 29 Aug 2001 17:28:23 -0500
>
> >I have noticed that (interactive) jobs with a small timeslice
> >are more "reactive" than jobs with a large timeslice.
> >This seems to indicate that the OS/400 is not "truly"
> >preemptive. Is this observation correct, or am I missing
> >something, or should I even know?
> >
> >
> >
> >_______________________________________________
> >This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
list
> >To post a message email: MIDRANGE-L@midrange.com
> >To subscribe, unsubscribe, or change list options,
> >visit: http://lists.midrange.com/cgi-bin/listinfo/midrange-l
> >or email: MIDRANGE-L-request@midrange.com
> >
> >
> _______________________________________________
> This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
list
> To post a message email: MIDRANGE-L@midrange.com
> To subscribe, unsubscribe, or change list options,
> visit: http://lists.midrange.com/cgi-bin/listinfo/midrange-l
> or email: MIDRANGE-L-request@midrange.com
> ******************************************************************
>
> This email and any files transmitted with it are confidential
> and intended solely for the use of the individual or entity
> to whom they are addressed. If you have received this email in
> error please notify the system manager at:
>
>                    mailto:postmaster@eb.uk.com
>
> The recipient acknowledges that transmissions made via the Internet
> can be corrupted and therefore EB Plc and any of its subsidiaries
> do not give any warranty as to the quality or accuracy of any
> information contained in the message or assume any liability for
> it or for its transmission, reception or storage.
>
> This footnote also confirms that this email message has been swept
> by Anti-Virus software for the presence of computer viruses.
>
> http://www.eb.uk.com
> http://www.game.uk.com
>
> ******************************************************************
> _______________________________________________
> This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
list
> To post a message email: MIDRANGE-L@midrange.com
> To subscribe, unsubscribe, or change list options,
> visit: http://lists.midrange.com/cgi-bin/listinfo/midrange-l
> or email: MIDRANGE-L-request@midrange.com
>