RE: Why separate pools?

Probably, but as easy as it is to separate the two (and assuming you are not
memory constrained) why take the chance?  The first thing I was ever taught
about performance was to group like workloads.  I don't believe that you
need a separate pool for every subsystem or a separate subsystem for every
10 users, but it's relatively easy to separate batch from interactive and
base.  Why wait for a problem to manifest itself?  (Besides, if your users
are like mine they'll be screaming to VP's long before we would notice a
problem...)

Regards,
 
Scott Ingvaldson
iSeries System Administrator
GuideOne Insurance Group

-----Original Message-----
date: Tue, 23 Nov 2004 12:54:11 -0500
from: "Walden H. Leverich" <WaldenL@xxxxxxxxxxxxxxx>
subject: RE: Why separate pools?

>Time slices can control some things, but do you want an interactive job
to
>have to wait for a batch job to complete its (comparatively long) time
slice
>before it can run? 

But won't the job also yield as soon as it goes into a long wait? 

And since IO is a long wait, unless you're calculating something very
complex that doesn't include IO (SETI@HOME?) the batch job will yield
LONG before it eats up it's time slice, no?

-Walden

------------
   
This message and accompanying documents are covered by the Electronic
Communications Privacy Act, 18 U.S.C. §§ 2510-2521, and contains information
intended for the specified individual(s) only. This information is
confidential. If you are not the intended recipient or an agent responsible
for delivering it to the intended recipient, you are hereby notified that
you have received this document in error and that any review, dissemination,
copying, or the taking of any action based on the contents of this
information is strictly prohibited. If you have received this communication
in error, please notify us immediately by e-mail, and delete the original
message.