Path: utzoo!utgpu!watserv1!watmath!att!pacbell!pacbell.com!decwrl!sdd.hp.com!usc!apple!amdcad!mozart.amd.com!nucleus!davec
From: davec@nucleus.amd.com (Dave Christie)
Newsgroups: comp.arch
Subject: Re: Workstation Data Integrity
Message-ID: <1990Sep7.144514.19015@mozart.amd.com>
Date: 7 Sep 90 14:45:14 GMT
References: <19208@dime.cs.umass.edu> <1990Sep6.141040.3244@mozart.amd.com> <2496@crdos1.crd.ge.COM> <1990Sep7.003451.13193@portia.Stanford.EDU>
Sender: usenet@mozart.amd.com (Usenet News)
Reply-To: davec@nucleus.amd.com (Dave Christie)
Organization: Advanced Micro Devices, Inc., Austin, Texas
Lines: 21

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

	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.)


------------
Dave Christie