.nr HY 0
.nr PS 11
.nr VS 13
.TL
More on Clipper CPU upgrades for the undergraduate teaching machines
.AU
Martin Guy
Chris Downey
2 June 1988
.AB
This document considers what machine resources are needed for undergraduate
teaching.
The discussion considers in particular the consequences of using a Clipper
processor on the first year machine, and of merging the second and third
year machines into one with a Clipper.
.AE
.LP
Two largely separate issues are discussed here:
first, requirements for first year teaching, in particular with visual editing,
and second, possible plans for the second and third years.
.SH
Requirements for the first years
.LP
The aggregate load imposed by first year undergraduate teaching is quite small,
but it has very high peaks in supervised terminal sessions.
The largest classes the machine is required to support are of 25 users doing
interactive editing and running of their own programs.
.NH
Primary memory
.LP
The heaviest load would be 25 users, each with a shell and a visual editor.
The resident set sizes of these programs are 60K (the C shell) and 200K
(the vi editor) of data respectively, making 6.5M.
An idle Clipper with 8M of store has 6 megabytes of store on its free list,
so this would be sufficient.
Clipper memory is only available in units of eight megabytes.
.NH
Secondary memory
.LP
The program text segment of Clipper binaries is larger than the corresponding
code for a Mk0 CPU; sample programs show an increase in size of between 10
and 50 percent.
This size increase is directly reflected in the size of program binaries
stored on the disk.
.LP
The current set of system files for Clippers at UKC would not fit onto the
system (/usr) partition of the first year machine.
It might be possible to shoehorn it in by moving much of it onto the user
partition of the disk, but this partition does not at present have much
spare capacity.
.LP
In tests run on a VAX 750, the speed difference between the disk being
80% and 90% full was noticeable.
More on this later in the document\^.\^.\^.
.LP
The larger code size does not affect primary memory much because code resident
in the machine is shared, and only constitutes about 10% of the
occupied primary store, the rest being data.
.LP
Another use of secondary memory is for swap space.
In the above example (25 shells + 25 visual editors), we would need 17300K of
swap space for the user processes.
The system processes use 10 megabytes of swap, so the current configuration
of 32M of swap space would suffice.
.NH
Processor
.LP
The load imposed by a visual editor is almost purely on the processor.
It uses this for its own purposes to compute how to refresh the screen,
but most of the load is incurred by the kernel in context switches.
Because the editor has to perform character echo itself, it runs for a very 
short period as each character is pressed.
The amount of disk traffic caused by the editor while it is running is
negligible.
.LP
We ran some tests, having 25 first years in a class typing vigorously into
a visual editor.
The Mk0 Orion did just manage to support this load, with character echo
happening within a second of the keypress in most cases.
.LP
However, we would be reluctant to promote teaching of visual editing under
these conditions because there is no CPU headroom.
This would mean that when the students had finished editing and wanted to
compile their latest creation, it would take a long time, and would
slow down the remaining editors further.
.LP
Tests run by IBM on user interfaces claim that a response after
more than 200ms is perceived as a separate event from the input.
This is borne out by experience on the Occam course run on VMS, in which
character echo and editing responses did not occur even within a second.
This confused many users because they would see that nothing had happened,
and re-key their input, overshooting items they were trying to move to,
and deleting more lines than they intended.
.LP
On a Clipper with 24 users, \fIvi\fP's response seems immediate.
With 32 users, the delay is detectable, but not long enough to confuse
(still a small fraction of a second).
.SH
Requirements for second and third years
.LP
The loading on the second and third years' machines is much heavier than on the
first year machine, composed of assessed coursework and project work,
both of which are done in the student's time.  This means that the load is
more even, though the machines lie idle during lectures.
.LP
During the day, there are normally about ten processes competing for the
processor on each of these machines.
There is never any idle time for the processor at these times, so a
backlog of work forms.  A local peak in load causes the backlog to double
which takes about quarter of an hour to abate.
(Of course, these figures are only for what we've seen.
When the machines are heavily loaded, we avoid logging on to them at all.)
.LP
The processor is unable to get through the amount of work which the users
require to do their work, the workload being limited ultimately by making
the users wait for a long time for each job to complete.
.NH 0
Primary memory
.LP
We have experience of using Mk0 Orions with 4, 6 and 8 megabytes of memory.
With 4 they thrashed (excessive paging due to insufficient memory to hold
the working set of all active processes), 6 was adequate and 8 is comfortable.
Since 90% of the memory use is in data, not text, this experience should
translate to Clippers directly.
.LP
However, it does not follow that if we use one machine to support both the
second and third years, then these figures need to be doubled.
.IP \(bu
On a Mk0 Orion with eight megabytes, the kernel occupies 1.4M of store,
as opposed to 0.85M on a Clipper, so in fact we get more of the 8
megabytes for user processes.
(On a Clipper, separate memory is used for the disk buffer cache, whereas
the Mk0 kernel takes a proportion of the available user memory)
.IP \(bu
Some of the memory is required by system processes.  Both an 8 megabyte Mk0
and an 8 megabyte Clipper have about six megabytes of memory free when they
are idling.  This suggests that about one megabyte is required by
system processes in user space.  This figure is the same pretty much
regardless of the number of users the machine supports.
.IP \(bu
Because one Clipper is much faster than two Mk0 Orions, the backlog of work
should not build up, so less processes will be resident in memory at once.
.IP \(bu
Having two distinct user populations on the machine will tend to even out the
load over time because the gaps in the two timetables will tend not to
correspond (by accident, not by design).
.IP
A mechanism already exists to ensure that assessment deadlines do not
coincide, to avoid overloading students.
The second and third year deadline convenors can help
avoid two simultaneous machine-intensive assessments.
.LP
These factors suggest that eight megabytes of memory should be sufficient,
since the machine would not be expected to support twice the loading peaks
seen on one of the existing machines, but yet would have more memory
available than one of the existing machines.
.NH
Secondary memory
.LP
The size of the user partition on the first year machine is 70 megabytes,
and on the second and third year machines it is 317 megabytes each.
In practice we never want to run these fuller than 50M and 230M used because
above this, the 4.2BSD Unix disk block placement strategy finds it increasingly
difficult to pick optimally-placed disk blocks for new files.
.LP
With a small amount of encouragement for the users to have a periodic 
clean out, and keeping tabs on very heavy users, these disks do not fill up.
It appears that the maxim
.ft I
disk usage expands to fill the space available
.ft
does not hold, and that we currently have enough by a comfortable margin.
.LP
Each of the machines with a big disk has enough space to keep a compressed
backup of the users' files from the other, and one of them keeps a backup
of the first year users' files.
This has proved most valuable on several occasions.
.LP
Coalescing two machines gains us a lot of disk space.
We only need to keep one copy, instead of two, of the news (34M) and system
files (about another 30M).
With this taken into account, one way to rearrange the machine to advantage
would be to put one of the big disks on the first year machine, and to use
the other big disk and the small one to make up the second and third year
machine.
This would also get round the problem of the first year machine's disk
being inconveniently small to hold a Clipper system.
.LP
A machine with two spindles is generally held to perform much better than
a machine with one.
As disk traffic is not the limiting factor in the machines' performance at
present, this is unlikely to give as dramatic improvement in performance as
the CPU upgrade.
However, it is another bonus.
.NH
Processor
.LP
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 these machines usable.
.LP
When we were running a monitoring program (\fIvmstat\fP) on these machines,
to show the occurrence of thrashing when we only had 4 megabytes of memory
in each machine, the CPU was hardly ever idle at all during the day.
Disk traffic was not large (particularly when compared to the traffic when
the machine \fIwas\fP thrashing).
.LP
It is not clear exactly how much processing power the second and third years do
need, but the current processors' sloth impedes students' work to a large
degree.
.SH
General remarks on Clippers
.LP
There are currently three machines at Kent which have Clipper processors.
Only one of these, Raven, experiences a load similar to that on one of the
teaching machines.
With 32 users, the machine's response is not noticeably slowed; the response
to most simple commands is within a second or two.
Surprisingly, the response does not degrade significantly when the cruellest
wrecking programs are run on it, programs specifically designed to cripple
the machine in one of a variety of ways.
Under the influence of these programs, a Mk0 Orion is unusable.
.LP
There are some doubts about relying on Clippers.
The C compiler has been buggy, and for some months earlier this year,
a heavily used machine would crash without warning every couple of days
due to an untraceable kernel bug.
This is characteristic of the reliability of software run on Clipper Orions,
and the kernel problems get worse the more heavily loaded the machine.
If we use Clippers more, we can expect more bugs of this magnitude to appear,
and the more sophisticated students are sure to spot more problems which lie
as yet undetected.
.LP
That said, we have been running a user service on Raven for six months with
less problems than we experienced on the Mk0 Orions in the early months.
.SH
Summary
.LP
We need to upgrade the first year machine to a Clipper be able to teach
visual editing.
We can just fit a clipper system on the existing disk of the first year
machine, but it would be uncomfortably tight.
.LP
We believe that one clipper processor with just eight megabytes of memory is 
sufficient to support the second and third years, and that by doing this
the needs of all three years would be served by putting a 400M drive on
the first year machine, and a 400M and a 168M drive on the second/third
year machine.