Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!cornell!uw-beaver!rice!sun-spots-request
From: dupuy@cs.columbia.edu (Alexander Dupuy)
Newsgroups: comp.sys.sun
Subject: 32MB on new Sparc Server?
Keywords: Hardware
Message-ID: <8905081818.AA22009@cs.columbia.edu>
Date: 11 May 89 11:58:24 GMT
Sender: usenet@rice.edu
Organization: Sun-Spots
Lines: 37
Approved: Sun-Spots@rice.edu
Original-Date: Mon, 8 May 89 14:18:46 EDT
X-Sun-Spots-Digest: Volume 7, Issue 283, message 10 of 13

>From the price list, it would seem that the Sun-4/300 series comes with 8
megabytes on the CPU card, and that expansion memory cards of 24 megabytes
are available - as this is the most reasonable combination for the two
available memory sizes: 32 and 56.

What's most interesting is that this is _not_ ECC memory like the
Sun-4/200 series uses, but apparently only parity-checked.  Parity
checking is fine when you don't have much memory, since failures are less
common, but once your memory size starts getting up there (56 megabytes is
quite a bit for a Sun) the possibility of chip failures tends to increase
proportionally.

With ECC memory, you can run for quite a while with a marginal (or even
broken) chip - certainly long enough to get a replacement board or to
schedule downtime to replace the failing chip (the ECC subsystems usually
give you enough information to pinpoint the failing chip).

I guess Sun either has a lot of confidence in their memory chip suppliers,
or they're trying to increase the sales of 2-hour response maintenance
contracts.  :-) I heard from a friend that a Sun salesthing let slip that
Sun were not terribly pleased with the new memory architecture on the -300
series, and that there probably wouldn't be any other machines in that
series.  One possibility is that marketing (price/performance and
competitive) considerations played a role in the memory design.

In response to your second question, there is a good reason why you might
want to have a server with 32 megabytes just to serve 10+ diskless
clients: disk caching.  Under 4.0, almost all of memory is potentially
available for I/O buffering.  A diskless client which goes across the
ethernet to access disk which is cached in memory there will almost
certainly see better response times than a diskful client going to a
relatively slow SCSI disk.

@alex
-- 
inet: dupuy@cs.columbia.edu
uucp: ...!rutgers!cs.columbia.edu!dupuy