From owner-freebsd-hackers Sun Oct 26 19:07:35 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id TAA08378 for hackers-outgoing; Sun, 26 Oct 1997 19:07:35 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from server.local.sunyit.edu (A-T34.rh.sunyit.edu [150.156.210.241]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id TAA08373 for ; Sun, 26 Oct 1997 19:07:33 -0800 (PST) (envelope-from perlsta@cs.sunyit.edu) Received: from localhost (perlsta@localhost) by server.local.sunyit.edu (8.8.7/8.8.5) with SMTP id XAA19948; Sun, 26 Oct 1997 23:12:34 -0500 (EST) X-Authentication-Warning: server.local.sunyit.edu: perlsta owned process doing -bs Date: Sun, 26 Oct 1997 23:12:33 -0500 (EST) From: Alfred Perlstein X-Sender: perlsta@server.local.sunyit.edu To: Tom cc: hackers@FreeBSD.ORG Subject: Re: Parity Ram In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > more bits means more chance of error even if they are "error-correcting" > > bits? > > And how is that bad? Even simple parity systems will catch 100% of all > single bit errors, regardless of where the bit appears. > > More bits mean more redundancy. That means it gets safer, not riskier. ok, 9 to 8 is a 1.125 difference in the ratio? i think, what he means is that with a large amount of memory you just have more bits that can go bad... i'm not really sure though, just playing devil's advocate... you still have the same amount of protection, just more risk.