Path: utzoo!utgpu!jarvis.csri.toronto.edu!clyde.concordia.ca!uunet!bnrgate!bigsur!bnr-rsc!bcarh185!schow
From: schow@bcarh185.bnr.ca (Stanley T.H. Chow)
Newsgroups: comp.arch
Subject: Re: Parity (was: Time between memory failure)
Message-ID: <2127@bnr-rsc.UUCP>
Date: 8 Feb 90 18:59:13 GMT
References: <1911@sunquest.UUCP> <38420@apple.Apple.COM>
Sender: news@bnr-rsc.UUCP
Reply-To: bcarh185!schow@bnr-rsc.UUCP (Stanley T.H. Chow)
Organization: BNR Ottawa, Canada
Lines: 15
Summary:
Followup-To:
Keywords:

In article <38420@apple.Apple.COM> baum@apple.UUCP (Allen Baum) writes:
>Actually, especially when it comes to PCs, parity migh be a loss rather
>than a win, but not for the reasons you'd suspect. Often, it's the parity
>generating circuitry that's the critical path, and it fails more often than
>the memories. Thus, you get lots of parity errors that aren't really errors.
>Its the parity checking and generating circuitry that's the weak point.

But surely the point is Total-undetected-error-count. Yes, it is annoying
to have errors introduced by the checking circuitary but that is secondary
to catching all real errors.

Stanley Chow        BitNet:  schow@BNR.CA
BNR		    UUCP:    ..!psuvax1!BNR.CA.bitnet!schow
(613) 763-2831		     ..!utgpu!bnr-vpa!bnr-rsc!schow%bcarh185
Me? Represent other people? Don't make them laugh so hard.