From owner-freebsd-questions Mon Jul 14 05:47:34 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id FAA19093 for questions-outgoing; Mon, 14 Jul 1997 05:47:34 -0700 (PDT) Received: from gatekeeper.barcode.co.il (gatekeeper.barcode.co.il [192.116.93.17]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id FAA19067 for ; Mon, 14 Jul 1997 05:47:14 -0700 (PDT) Received: (from smap@localhost) by gatekeeper.barcode.co.il (8.8.5/8.6.12) id PAA24718; Mon, 14 Jul 1997 15:44:24 +0300 (IDT) X-Authentication-Warning: gatekeeper.barcode.co.il: smap set sender to using -f Received: from localhost.barcode.co.il(127.0.0.1) by gatekeeper.barcode.co.il via smap (V1.3) id sma024716; Mon Jul 14 15:44:13 1997 Message-ID: <33CA1F23.1876@barcode.co.il> Date: Mon, 14 Jul 1997 15:44:19 +0300 From: Nadav Eiron X-Mailer: Mozilla 3.0 (X11; I; SunOS 5.5 sun4m) MIME-Version: 1.0 To: dmaddox@scsn.net CC: Wes Peters - Softweyr LLC , Nick Johnson , questions@FreeBSD.ORG Subject: Re: A few solutions References: <199707140404.WAA07219@xmission.xmission.com> <19970714072626.64852@scsn.net> <33CA1547.AD3@barcode.co.il> <19970714082521.61598@scsn.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-questions@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Donald J. Maddox wrote: > > On Mon, Jul 14, 1997 at 03:02:15PM +0300, Nadav Eiron wrote: [snip] > > Well, all I can say is that according to the User's Manual for my > ASUS P/I-P55T2P4 mainboard, all I need for ECC is parity RAM, and > ECC enabled. > > I notice, however, that the ECC supported by this MB only supports > 1-bit error correction... Maybe the ECC RAM you two are speaking of > allows for more sophisticated error correction? Probably. Saying they correct 1 bit is not a complete specification of the strength of the code they use. You need to know one bit out of how many. Standard parity RAM uses one extra bit per byte, and can detect one bad bit per byte. By aggregating these extra bits from more than one byte you may be able to, say, correct one bit in 32bits or such (sorry, didn't make the calculations, I took coding theory back when I was doing my M.Sc. and I don't remember that much :-( ), but depending on the kind of errors you have, this may be better *or* worse than just parity. If you have 32bits with 4 bad bits, each in a different byte, standard parity will detect it, but this type of ECC won't. There is no such thing as a free lunch, at least not in coding. Nadav