Re: Timeslice recommendations

Jay,

Activity level is released when the job ends ... I'm 99.44% sure of that
... most of those server jobs don't end ... they go into long waits instead.

As John Carr said in his post ... there are a lot of interrelated variables
that have to be considered ...

The main points are:
   - what goals are you trying to accomplish?
   - what is the specific situation on your server?

Pete Hall's situation (cutting all timeslices in 1/10) might have been OK
for a few jobs that misbehaved with a lot of "short code path" jobs (or
else he didn't have a lot of contention for memory) ... every situation is
different ... those that have one stock answer for tuning a '400 end up
missing the point!!!

BTW:  The Orbb.org database must have scanned us just after our V5R1 update
... the anti-mail-relay mechanism seems to have changed from V4R5.  The
relay has since been closed (as per orbz.org) !

John

At 10:00 AM 2/11/2002, you wrote:
>X-Note: This E-mail was scanned by Declude JunkMail (www.declude.com) for
>spam.
>
>John,
>
>I liken the tuning of  the timeslices to the high speed jet on a carburator.
>Too rich (ie too large a time slice) and it bogs down on heavy load and
>won't recover till the load is removed. Too lean (ie too small a time slice)
>and the system really sputters. On the AS/400-iSeries that would equate to
>Wait-to-Inel. So far that hasn't occured with the timeslices I have
>currently set. I wonder if anyone has hit the point of too-lean.
>
>It is my understanding that the 400 will hold that memory until the
>timeslice is complete, even if the job has long past completed. That is why
>I keep trying smaller timeslices.
>
>The other classes I mentioned are for TCP and Spool services. If a TCP
>service has a 2000 millisecond timeslice and the transaction only takes 20
>milliseconds, then given the heavy TCP load on today's 400's (iSeries),
>there would be more memory that could be recovered for immediate processing.
>
>I think this is important on the 7XX boxes, cause IBM chooses to kill the
>batch CPW when the interactive feature is maxed.
>
>Thanks for your feedback.
>
>Jay
>
>p.s. your email server has hit the ORDB database.
>X-RBL-Warning: Blackholed by ORDB -- see
><http://ordb.org/lookup/?host=207.113.29.10>
>
>
>----- Original Message -----
>From: "John Myers - MM" <jmyersmm@sbsusa.com>
>To: <midrange-l@midrange.com>
>Sent: Friday, February 08, 2002 3:20 PM
>Subject: SPAM: Re: Timeslice recommendations
>
>
> > Jay,
> >
> > If you don't know what they are (I don't recognize them either), don't
> > touch them!  You can back into what they do by matching up the routing
>data
> > on the routing step that uses the class with various system job
>descriptions.
> >
> > Timeslice values should not be driven by the speed of the main processor
>or
> > the amount of Interactive CPW that you have purchased!
> >
> > The purpose for timeslices is to determine what is the maximum time a task
> > has access to an activity level (being resident in memory) before you make
> > it compete to keep it.
> >
> > It is generally a bad thing if a routine interactive task has to give up
> > its activity level before it concludes.  Someone running a "batch-like"
> > task in Interactive is another story.  Some application software packages
> > have very long code paths that take awhile to complete.  Others have very
> > short code paths & will complete in a much shorter time.  The times also
> > vary with the number of tasks that are resident in memory at once!  The
> > correct timeslice values for Interactive can vary greatly between systems.
> >
> > Like any other performance tuning issue, the important issue is the goal
> > that you are trying to reach &  what you are willing to give up to reach
> > that goal.
> >
> > Are you tuning because Interactive performance is slow?
> >
> > If CFINT has kicked in (& the you are unwilling to buy more processor),
> > optimizing your interactive performance is probably the best step.  CFINT
> > slows down your entire machine.
> >
> > Do you have Interactive jobs that transition from active to
> > ineligible?  That is a sign that they are exceeding their timeslice at a
> > time when your main memory is over committed.
> >
> > Sorry for the scattershot answer, but tuning is like seeing a doctor ...
> > what do you say after saying AAAHHHHHHHHH????
> >
> > Hope this helps!
> >
> > John Myers
>
>
>
>_______________________________________________
>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
>Before posting, please take a moment to review the archives
>at http://archive.midrange.com/midrange-l.