Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!rutgers!mit-eddie!genrad!decvax!decwrl!ucbvax!HARVARD.HARVARD.EDU!sasaki
From: sasaki@HARVARD.HARVARD.EDU (Marty Sasaki)
Newsgroups: mod.computers.vax
Subject: Query about priorities in VMS
Message-ID: <8703190747.AA23958@ucbvax.Berkeley.EDU>
Date: Thu, 19-Mar-87 02:45:27 EST
Article-I.D.: ucbvax.8703190747.AA23958
Posted: Thu Mar 19 02:45:27 1987
Date-Received: Sat, 21-Mar-87 04:50:08 EST
References: <0543063732@uwovax.UWO.CDN>
Sender: daemon@ucbvax.BERKELEY.EDU
Distribution: world
Organization: The ARPA Internet
Lines: 51
Approved: info-vax@sri-kl.arpa

Adding low priority batch jobs may have a dramatic impact on the
overall performance of a VMS system, so it isn't as easy as saying yes
or no to Brent's questions.

As an example, suppose that the system with regular interactive loads
is using 80% of the physical memory available (working sets have been
adjusted and all of that). Now imagine adding a few batch jobs.
Depending on what these added processes are doing, their individual
quotas, working sets, and such, you might suddenly be using all of
real memory (and needing more), and paging like crazy. If you have set
your sysgen parameters right (or wrong) you might even be swapping.

The scenario that I just presented is more likely than not, especially
in a university environment. When researchers see the cheap rates,
they will submit big programs. At Harvard many of the jobs were SPSS
and SAS jobs with huge datasets, or simulations with lots of array
manipulation (imagine a two dimensional fourier transfer on a 1024 by
1024 array :-) ).

We had four batch queues, quick$batch, sys$batch, slow$batch and
back$batch. Each with declining priority with quick$batch running at
priority 5, but with a 5 minute CPU limit. (Actually, we had another
batch queue sysonly$batch which we used for system things like
accounting and special backup routines.

There is also another phenomena which might not be an issue on version
4 of VMS, but was on version 3. It was possible for processes to get
in a state where batch jobs, with the priority boost after doing disk
i/o, would steal CPU cycles from interactive programs. This was most
noticeable with programs like EDT and Emacs which would momentarily
go compute bound while calculating screen updates. This would cause
their priority to fall below batch jobs. If there were enough batch
jobs doing disk i/o followed by a little calculation, but not enough
to bump their priority down, the "interactive jobs" might have to wait
a long time to get the CPU.

At Harvard, my solution to this problem was to move the base priority
of interactive jobs up to 7. I ran the version 4 systems this way too,
but never tested to see if this problem occured on version 4.

Having a slightly higher load might mean tweaking sysgen parameters a
little. When I increased the job limit on the queues, I played with
the paging/swapping parameters, QUANTUM, and IOTA to squeeze a little
bit more out of the system.

So, the answer is, "it depends".
----------------
  Marty Sasaki				uucp:   harvard!sasaki
  Ziff Davis Technical Information Co.	arpa:	sasaki@harvard.harvard.edu
  80 Blanchard Road			bitnet: sasaki@harvunxh
  Burlington, MA 01803			phone:	617-273-5500