Article View: comp.arch
Article #22279Re: Parity (was: Time between memory failure)
From: Stanley T.H. Chow
Date: Thu, 08 Feb 1990 18:59
Date: Thu, 08 Feb 1990 18:59
15 lines
1341 bytes
1341 bytes
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.
Technical Details
Message-ID:
<2127@bnr-rsc.UUCP>Path:
arc1-ca.pugleaf.net!utzoo!utgpu!jarvis.csri.toronto.edu!clyde.concordia.ca!uunet!bnrgate!bigsur!bnr-rsc!bcarh185!schowReferences:
<1911@sunquest.UUCP> <38420@apple.Apple.COM>Show Full Headers
Complete Article Headers
Path: arc1-ca.pugleaf.net!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