response 26 of 37:

Mar 17 05:33 UTC 1998

We have a case sitting in the Pumpkin.  Let me know when you want to pick it
up (late evenings are probably best).

response 28 of 37:

Mar 20 04:16 UTC 1998

Late evenings are fine.  After this weekend I should be free.

response 30 of 37:

Mar 24 04:51 UTC 1998

I think the argument was that, since SunOS isn't multithreaded, more CPU's
wouldn't help much.  We do have another one we could possibly put in and test
with.

response 32 of 37:

Mar 24 06:25 UTC 1998

The SunOS kernel isn't multi-threaded, so only one process can be
executing kernel code at a time.  Grex, like most typical Unix systems,
spends about 50% of its time in kernel mode.  This means Grex can make
good use of 2 processors, because (on average) one processor can be in
the kernel while the other one is executing user code.  In theory, with
3 or more processors, the fact that only one processor can be executing
kernel code becomes the limiting factor, and performance should not be
significantly better than with 2 processors.  It could be worse if there
is any significant penalty for extra processors.

Obviously, in SunOS, the MP support is pretty primitive.  It is possible
to fix this, basically by completely rewriting the kernel.  Sun has done
this, and the result is called Solaris 2.  Solaris 2 can, in fact, make
good use of many processors, however, for a uniprocessor system, the
resulting MP overhead actually hurts performance.

Rather than trying to deploy a single large MP system, however, there is
another very different architectural approach, and that is to implement
a real distributed environment.  Basically, this means deploying a
number of smaller loosely coupled machines, and splitting up the stuff
that you see here on grex, between these multiple machines.  That might
mean, for instance, a few file servers, an authentication server, a mail
server, several login machines, and several terminal servers.  This
architecture has some important advantages over a monolothic large MP
server; for instance, if a machine breaks, it's easier to take it out of
service and replace it.  This architecture also scales better (up to
thousands of online users at once), and is in some ways much more robust
(something that clogs up the mail server with tons of mail may barely
affect anything else.)

Another important advantage (for grex) is that new MP servers are
extremely expensive, and used MP servers are not likely to be at all
common; while the "small server" distributed environment can make good
use of used workstations, which are extremely common.

response 34 of 37:

Mar 25 23:54 UTC 1998

Faster disks will make very little difference with kernel overhead.  The
kernel overhead for a scsi disk of any speed will be virtually
identical, consisting of the time to set up the control blocks, pass
them to the controller, and later, to respond to the interrupt from the
controller when the transfer is done.  The speed of the disk is
completely irrelevant for these 2 activities; they'll take almost
exactly the same amount of CPU no matter how fast (or slow) the disk is.
7200RPM drives will have lower rotational latency, which will certainly
make things more spiffy, but may also have higher transfer rates, which
(if the controller is capable of it), could actually "hurt" CPU
performance by eating more memory bandwidth.  (The "hurt" disappears
when you consider overall system performance; it takes the same # of
memory cycles to transfer disk data to memory, regardless of whether
it's all squashed together or spread out a bit.) 7200RPM drives would
certainly still help performance, but finding a disk with fast seek
times is probably more important.

This is very different from the PC world, where with IDE, a faster disk
might well result in improved CPU utilization.  IDE disks don't do DMA,
but instead, the CPU transfers the data from the disk.  I've seen one
report that on some newer machines, an IDE drive can eat about 50% of
the CPU, vs. about 10% for a similar SCSI disk.  A faster spinning IDE
drive might well be able to manage faster transfer rates, and thus take
less CPU.

response 36 of 37:

Mar 26 04:50 UTC 1998

You can get a good idea of how much a faster disk will help throughput 
on Grex by looking at the queue lengths as reported by vmstat. 
Try vmstat 5 and let it run for a minute or two.

Because the "r" queue lengths completely dominate the "b" numbers, I am 
not convinced that a faster disk will speed things up very much. More 
CPU might even help more than disk, even under SunOS 4.1.4, though the 
need for more CPUs is not as great for performance as it is for backup.

Grex effectively uses all the time while waiting for disk IO to complete 
by running other processes. If we did have a disk with higher IO rates, 
though, swap would be the first choice for where to put it, simply to 
make sure that there were always enough processes in memory to keep the 
CPUs busy. It seems there are, though, in our 128M of Ram.