.TL
Some points about machine loading
.AU
Chris Downey
Martin Guy
20 May 1988
.PP
The three teaching machines \fBfalcon\fP, \fBgos\fP and \fBmerlin\fP
have now been in service for a few years, and we can start
to analyse their overall performance, and make recommendations
about what we think could be done to improve it.
.PP
We do not wish to present hard data here, as this is
meaningless on its own; our recommendations are drawn from
a wealth of statistics taken from all three hosts, as well
as comments and complaints from the students, and our own
experiences in using the machines.
Another point to be made here is that the factors
taken into consideration interact in complex ways;
we have had lengthy discussions with the Hardware Group,
and with the rest of the Unix Support Group, about this.
.SH
Machine Loading
.IP \(bu
We received one complaint from a student who waited 15 minutes
between typing ``em file'' and getting the `>' prompt from em.
.IP \(bu
We constantly receive complaints from students who have to
do their work late at night because they cannot get access
to the machine during the day; there are too many others
wanting to use it at the same time.
.IP
Because each machine is used by
a single year, they remain largely idle when the students
have lectures or classes.
.IP \(bu
For most of the academic year, falcon and gos have a load
factor of about 10 simultaneous processes competing for the processor
during the day.

The real problem here, however, is lack of \fICPU headroom\fP;
because there are no spare processor cycles, all it takes is
one person to set off an extra background job to start the
machine thrashing, making it unusable for 10 to 20 minutes.
(This is exactly what used to happen to eagle a few years
ago, when it had more users and less memory.)
.IP \(bu
Many of the ``better'' (or more enthusiastic) second- and
third-year students already use a screen editor.
We rely on the existence of less enthusiastic students
(who still use em in their third year)
to keep falcon and gos usable.
.SH
Processor
.LP
Deciding whether a computer's processor power is sufficient,
and whether a faster CPU will actually result in a faster machine,
is extremely difficult.
However, the main reason we want faster processors on the
teaching machines is so that we can teach a screen editor,
and this makes the problem much simpler.
Screen editors use a lot of I/O bandwidth, and consequently
a lot of processor. Once the I/O hardware is sufficient,
the only thing which slows down screen editing is how fast
the CPU can respond to interrupts and do context switches,
because that is what it will be doing most of the time.
A faster processor can handle interrupts faster,
and switch between processes faster.
.SH
Disks and Memory
.PP
We believe that the disks on the teaching machines have
sufficient capacity for the needs of the students; in fact,
falcon's disk has remained about half full for the last
two years. This is probably largely due to the changing
population on the machines, and the fact that we insist
on people's logins being wiped when they leave.
.PP
Of course, total capacity is not the only measure of whether
a computer's disks are sufficient; the number of spindles
is very important, and even a small extra disk can result
in quite dramatic improvements in performance.
.PP
One problem that was experienced is lack of \fIswap space\fP;
re-configuring the disks to provide an extra swap partition
largely solved this problem, but unfortunately this accentuated
the degradation in performance experienced when the machine runs
out of memory, thus requiring more RAM to be installed.
All three machines now have 8Mbytes of main memory, and
this aspect of their performance is now satisfactory.
.PP
It should be noted here that because Clipper binaries
are roughly twice the size of Orion binaries,
a Clipper with 8Mbytes of main store is much more
likely to thrash than an Orion with the same amount of memory.
This effectively reduces the maximum number of users that may
be logged in, resulting in a possible waste of resources.