JAMES@VAXE.COE.NORTHEASTERN.EDU (James Jones) (12/20/86)
Hi, I heard a rumour from a person I know at DEC concerning what is the best base priority for a VMS system. Normally, most systems seems to have 4 as the base priority for interactive and batch jobs, with batch jobs being lowered depending on the system load. The person I spoke to mentioned hearing that the best base priority is 5 rather than 4. He spoke of the algorithm used by the swapper (I believe it was the swapper that he referred to) being made more efficent by using 5 rather than 4. Has anyone heard about this? Does it make sense to do this? In a related subject, how about a setup with interactive jobs at 4 (or whatever the base priority is) and batch jobs at 1 less than the interactive jobs? Will this improve or degrade system performance? Thanks in advance for any replys, James Jones Northeastern University College of Engineering Boston, Massachusetts 02115 (617)437-4430 CSnet address: JAMES@VAXE.COE.NORTHEASTERN.EDU
LEICHTER-JERRY@YALE.ARPA.UUCP (12/24/86)
I heard a rumour from a person I know at DEC concerning what is the
best base priority for a VMS system. Normally, most systems seems to have
4 as the base priority for interactive and batch jobs, with batch jobs
being lowered depending on the system load.
False. Normally, the base priority for interactive jobs is, indeed, 4. The
base priority for batch jobs is a parameter of the queue. If it isn't set,
it, too is 4; however, the default startup parameters for SYS$BATCH set its
base priority to 3.
(More accurately: The base priority for a non-batch process that goes through
LOGINOUT is a SYSUAF parameter, which if not specified defaults to 4. The
SYSGEN parameter DEFPRI is the default priority for processes that don't have
a priority set up in any other way. DEFPRI is normally 4.)
Once the base priority is determined, the manipulation of the priority is the
same for all classes of processes. (Interactive processes will tend to have
higher actual priorities than batch processes of the same base priority
because the priority boosts for terminal I/O are the highest used.)
The person I spoke to
mentioned hearing that the best base priority is 5 rather than 4. He
spoke of the algorithm used by the swapper (I believe it was the swapper
that he referred to) being made more efficent by using 5 rather than 4.
Has anyone heard about this?
No.
Does it make sense to do this?
No. As far as I know, the actual priority values have no effect on the
swapper, or anything else, except for the <16 (interactive)/>15 (real time)
distinction. (I don't remember off-hand whether it is possible to get a
priority increment into the real-time range. I don't think so, but if you
could, I suppose it would be more likely with a base of 5 than with a base
of 4. With an effective priority of 16 or higher, you'd be competing with
VMS processes like the swapper, as well as any actual real-time processes.
I suppose this might make the system appear more responsive under certain
conditions, but it seems unlikely. It could also have deleterious effects
on the system.)
In a related subject, how about a setup with interactive jobs at 4
(or whatever the base priority is) and batch jobs at 1 less than the
interactive jobs?
What you've described is the default.
Will this improve or degrade system performance?
"System performance" is a difficult thing to pin down; there are a lot of
tradeoffs involved. For example, there is typically a tradeoff between
throughput - number of jobs completed in an hour - and responsiveness - delay
in responding to the terminal. Throughput is maximized by favoring batch
processing - moderate/high priority for batch jobs, large quantum value,
large working sets, smaller number of process slots. (The general strategy
is to get just enough processes into memory so that one is always available
to run, then keep each of those processes running as long as possible by
minimizing scheduling events and page faults.) Responsiveness is maximized by
favoring interactive processes - high priority for such processes, small
quantum value, maximum number of process slots implying smaller working sets.
(The general strategy here is based on the idea that most interactive pro-
cesses are small and have small bursts of CPU usage interspersed with long
inactive periods while the user thinks; hence, maximize the chance that all
the interactive processes can be kept in main memory, ready to go as needed;
and when there are a couple, rotate among them often as they are highly likely
to finish quickly anyway.)
As a general rule, random mucking around with the VMS parameters will make
things worse. System tuning requires a careful analysis of your goals, your
resources, and your current and expected load. A careful reading of the
Guide to Performance Management is a mandatory first step.
-- Jerry
-------