From owner-freebsd-hackers Sun Oct 26 19:20:10 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id TAA08949 for hackers-outgoing; Sun, 26 Oct 1997 19:20:10 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from misery.sdf.com (misery.sdf.com [204.244.210.193]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id TAA08943 for ; Sun, 26 Oct 1997 19:20:06 -0800 (PST) (envelope-from tom@sdf.com) Received: from tom by misery.sdf.com with smtp (Exim 1.73 #1) id 0xPfhB-00072V-00; Sun, 26 Oct 1997 19:18:25 -0800 Date: Sun, 26 Oct 1997 19:18:24 -0800 (PST) From: Tom To: Alfred Perlstein 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 On Sun, 26 Oct 1997, Alfred Perlstein wrote: > > > 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... All the more reason to use parity. > i'm not really sure though, just playing devil's advocate... > > you still have the same amount of protection, just more risk. The same goes for everything. If the MTBF of one item is X, the MTBF of N such items is X/N. Tom