Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.1 Fluke 8/7/84; site fluke.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!mhuxl!houxm!houxz!vax135!cornell!uw-beaver!microsoft!fluke!kurt
From: kurt@fluke.UUCP (Kurt Guntheroth)
Newsgroups: net.micro
Subject: another *parity* argument
Message-ID: <1217@vax2.fluke.UUCP>
Date: Wed, 8-Aug-84 12:05:38 EDT
Article-I.D.: vax2.1217
Posted: Wed Aug  8 12:05:38 1984
Date-Received: Sat, 11-Aug-84 01:12:01 EDT
References: <692@sri-arpa.UUCP>
Organization: John Fluke Mfg. Co., Everett, WA
Lines: 19

Here is another thought.  What do you do with parity once you detect an
error.  This is true for hospitals and fire stations too.  A parity
error or other non-recoverable memory error trashes whatever you were
doing.  If it was an instruction fetch, the state of the machine is
trashed unless you are lucky to have a machine like the 32000 that can
do instruction restart (does the 68010 design recover from parity
errors?) Even if parity error happened in data, you may have changed
the status flags or some such.  Anyway, for many processors, there is
no way to recover from a parity error, so all parity does for you is
tell you that things have just been trashed.  Typical recovery from
parity errors is to halt waiting for reset.

So even for critical applications, parity may not be enough.  Either you
have ECC or you forget it.
-- 
Kurt Guntheroth
John Fluke Mfg. Co., Inc.
{uw-beaver,decvax!microsof,ucbvax!lbl-csam,allegra,ssc-vax}!fluke!kurt