Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!decwrl!shelby!portia.stanford.edu!dhinds
From: dhinds@portia.Stanford.EDU (David Hinds)
Newsgroups: comp.arch
Subject: Re: Workstation Data Integrity
Message-ID: <1990Sep7.003451.13193@portia.Stanford.EDU>
Date: 7 Sep 90 00:34:51 GMT
References: <19208@dime.cs.umass.edu> <1990Sep6.141040.3244@mozart.amd.com> <2496@crdos1.crd.ge.COM>
Organization: AIR, Stanford University
Lines: 22

In article <2496@crdos1.crd.ge.COM> davidsen@crdos1.crd.ge.com (bill davidsen) writes:
>In article <1990Sep6.141040.3244@mozart.amd.com> davec@nucleus.amd.com (Dave Christie) writes:
>
>| Its been many years since I designed EDAC for a 64-bit machine, but what
>| I seem to remember is that using 7 bits would only allow you to correct
>| the 64-bit data portion, not the 7 check bits themselves.  To cover those
>| you need one more bit (and you really do want those covered as well). 
>
>  I just looked at some C code for Hamming code I wrote years ago, and
>it appears to need log2(N)+1 bits, including the EDAC bits themselves.
>In any case, if you can have EDAC for the price of parity, why not?
>-- 
   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.
Using 8 parity bits per word amounts to catching most two-bit errors
as well - but catching more than single bit errors is not what parity
is tailored for.

 -David Hinds
  dhinds@popserver.stanford.edu