Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!yale!cs.yale.edu!blenko-tom
From: blenko-tom@cs.yale.edu (Tom Blenko)
Newsgroups: comp.sys.next
Subject: Re: memory (was: slab vs. cube and $$)
Message-ID: <27500@cs.yale.edu>
Date: 30 Nov 90 18:25:58 GMT
References: <1990Nov29.161041.15775@magnus.ircc.ohio-state.edu> <1990Nov30.013031.25032@mp.cs.niu.edu> <12108@life.ai.mit.edu>
Sender: news@cs.yale.edu
Organization: Yale University Computer Science Dept., New Haven, CT 06520-2158
Lines: 25
Nntp-Posting-Host: morphism.systemsz.cs.yale.edu
Originator: blenko@morphism.CS.Yale.Edu

|...  As the amount of memory increases, the chances go up that a
|bit will get flipped by a passing cosmic ray or that some chip or part
|of a chip will go bad.  Parity memory adds one bit to each word, which
|allows detection of single bit errors.  ECC (error correction code)
|memory adds a few more bits, which add enough redundancy so that words
|can be correctly reconstructed even if some bit(s) go bad.  A common
|form of ECC allows single bit error correction and double bit error
|detection.  Thus, it is possible to organize memory so that a passing
|cosmic ray or single failing chip needn't stop your machine; this
|security can be an important selling point for people who depend on
|their machine to accomplish their work.

First, there are a variety of ways that memories fail, and "a few more
bits" are not going to address all of them.  There are always cost ($$
and performance)/reliability tradeoffs.  I presume NeXT is offering the
option in order to garner government purchases (which sometimes require
parity memory).

Second, the subject of parity vs. non-parity memories has been
discussed at length in other newsgroups. It is usually non-productive:
not everyone's needs are the same, and the people with the most
loudly-voiced opinions often seem to know the least. Hence I suggest
NOT repeating the exercise here.

	Tom