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