More batch job problems

[David Hinds]

    We have an Iris 4D/240 system (4 processors), used for a combination
of interactive graphics and computation-intensive molecular dynamics
calculations.  We've been trying to find a way of managing processes that
will keep the machine fully utilized, but will still give reasonable
responsiveness for interactive work.  So far we have been unsuccessful.
    When all four processors are doing work (i.e., four batch jobs are
running), it is impossible to even log on to the console.  At first, we
thought this was a memory problem, but we've upgraded to 32MB now, and
this happens even when >4000 pages are free.  The console lockup happens
when all the batch processes are at maximum niceness (39), and still
happens even when they are all set to a non-degrading priority of 128
with npri.  As I understand it, at a priority of +128, these jobs should
not get even a second of CPU time if there are other demands on the system.
Interactive use on text-only terminals, however, seems normal under these
load conditions - editing, compiling, etc don't seem any slower.
    I expect that logging on to the console is a fairly expensive process.
But why is it so expensive that the system can't manage it in the presence
of background work?  It seems as if the console requires a CPU for itself
just to run.  Will this problem be corrected in the improved batch
facilities in the next software release?

 -David Hinds
  dhinds at portia.stanford.edu