Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!samsung!xylogics!transfer!lectroid!bigbootay!dswartz
From: dswartz@bigbootay.sw.stratus.com (Dan Swartzendruber)
Newsgroups: comp.arch
Subject: Re: Workstation Data Integrity
Message-ID: <2253@lectroid.sw.stratus.com>
Date: 7 Sep 90 16:54:28 GMT
References: <19208@dime.cs.umass.edu> <1990Sep6.141040.3244@mozart.amd.com> <2496@crdos1.crd.ge.COM> <1990Sep7.003451.13193@portia.Stanford.EDU> <1990Sep7.144514.19015@mozart.amd.com>
Sender: usenet@lectroid.sw.stratus.com
Reply-To: dswartz@bigbootay.sw.stratus.com (Dan Swartzendruber)
Organization: Stratus Computer, Software Engineering.
Lines: 36

In article <1990Sep7.144514.19015@mozart.amd.com> davec@nucleus.amd.com (Dave Christie) writes:
>In article <1990Sep7.003451.13193@portia.Stanford.EDU> dhinds@portia.Stanford.EDU (David Hinds) writes:
:
::   But don't you really only need one parity bit per word, if you only
::want to be able to detect single bit errors?  Using one parity bit
::per byte is wasteful - which is why the EDAC looks good.  Having one
::parity bit per 64 bit word would seem to be the more fair comparison.
:
:Yes, this would work, but 
:
:	1) it would take almost twice as long to check the parity,
:	   (7 levels of XOR vs. 4), and parity checking tends to be a
:	   time critical path (although sometimes you can delay it), 
:	   so it's a classic realestate/speed tradeoff

Beg pardon?  You're telling me that all of these parity checks are done
in serial???  If not, what difference does it make how many check bits
there are?

:
:	2) byte parity allows byte writes without the control complexity
:	   of doing read/modify/write.  (EDAC of course requires r/m/w
:	   for partial-word writes.)
:

This argument as least doesn't always hold when dealing with a write-back
cache.

:
:------------
:Dave Christie


--

Dan S.