Path: utzoo!attcan!telly!lethe!torsqnt!jarvis.csri.toronto.edu!mailrus!purdue!gatech!prism!vsserv!loligo!pepke
From: pepke@loligo (Eric Pepke)
Newsgroups: comp.sys.mac
Subject: Re: Parity vs. non-Parity RAM in the Mac IIci
Message-ID: <204@vsserv.scri.fsu.edu>
Date: 22 Sep 89 20:09:04 GMT
References: <0xe23@deimos.cis.ksu.edu> <34935@apple.Apple.COM>
Sender: news@vsserv.scri.fsu.edu
Reply-To: pepke@loligo.UUCP (Eric Pepke)
Organization: Supercomputer Computations Research Institute
Lines: 44

In article <34935@apple.Apple.COM> chuq@Apple.COM (Chuq Von Rospach) writes:
>Parity RAM is 9 bit ram SIMMS (and support hardware) instead of 8 bit ram
>SIMMS. Parity RAM is more expensive, not any faster and somewhat more
>reliable, although RAM reliability is high enough these days that unless
>you're writing RFC's for government contracts or totally paranoid, not
>terribly useful. 
>
>All parity does is check to make sure that the eight bits you wrote into the
>RAM come out again the same way (but only if you flip one bit. Parity
>doesn't cover multi-bit errors. You need ECC to do that).

Parity memory is less, not more, reliable than non-parity memory.  All that
parity does is, under certain conditions, alert the processor that a single
bit error has occured.  The effect of parity on most systems is to halt the
processor or kill the process rather than allow the program blithely to 
process the value on the assumption that it is correct.

Because parity requires an extra bit per byte, it actually increases the 
probability that bit errors will occur.  Assuming all the obvious things, 
parity memory will be about 9/8 as likely to fail within a period of time 
as non-parity memory.  About 1/9 of these failures will be failures of the 
parity bit which can be avoided by leaving the parity bit out of the system.

As far as multi-bit errors go, there is a well-known kind of ECC called
SECDED (Single Error Correction Double Error Detection), and it's obvious
what that does.  There are a lot of ways to detect multi-bit errors without 
using ECC, including the ever-popular CRC.

>There's no reason why a 'normal' user needs parity unless their applications
>require extremely high reliability.

Even a user who requires high reliability would not get it from parity.  
Parity would only benefit people who would rather see the system hang than
produce a wrong answer or execute a wild instruction.  Parity only changes
the kind of unreliability.  Which kind is the more desirable is debatable 
and may be a matter of taste.

Eric Pepke                                     INTERNET: pepke@gw.scri.fsu.edu
Supercomputer Computations Research Institute  MFENET:   pepke@fsu
Florida State University                       SPAN:     scri::pepke
Tallahassee, FL 32306-4052                     BITNET:   pepke@fsu

Disclaimer: My employers seldom even LISTEN to my opinions.
Meta-disclaimer: Any society that needs disclaimers has too many lawyers.