|
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
As an Amazon Associate we earn from qualifying purchases.
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.