Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!husc6!mit-eddie!ll-xn!ames!sdcsvax!ucsdhub!hp-sdd!hplabs!decwrl!alverson
From: alverson@decwrl.dec.com (Robert Alverson)
Newsgroups: comp.arch
Subject: Re: Double-bit errors and ECC memory
Message-ID: <50@bacchus.DEC.COM>
Date: Tue, 15-Sep-87 01:49:18 EDT
Article-I.D.: bacchus.50
Posted: Tue Sep 15 01:49:18 1987
Date-Received: Wed, 16-Sep-87 06:45:14 EDT
References: <1184@itm.UUCP> <797@spar.SPAR.SLB.COM> <2891@phri.UUCP> <7319@steinmetz.steinmetz.UUCP> <1215@nbires.UUCP>
Reply-To: alverson@decwrl.UUCP (Robert Alverson)
Organization: Digital Equipment Corporation
Lines: 18

In article <1215@nbires.UUCP> maa@nbires.UUCP (Mark Armbrust) writes:
>Not strictly true!  I can remember reading (sorry, too long ago to remember
>where) about a clever way to detect and correct all single bit errors, detect
>all double bit errors, and correct most double bit errors USING ONE BIT PER
>WORD.
... describes wonderfully convoluted ECC method.

The 1+log2(...) relation is *strictly* true.  This is a result from
information theory.  It seems to me that the scheme you mentioned lowers
the cost/bit of ECC by effectively using a larger word size.  Since the
number of check bits needed is logarithmic to the word size, you can
make the cost/bit arbitrarily low by working on more bits at once.  Note
that you don't get something for nothing.  Since you are checking over
more bits, there is a greater chance of multiple bit errors that you
cannot correct.  Also there is the mentioned hardware complexity of
the scheme you described.

Bob