From owner-freebsd-hackers Sun Oct 26 19:31:43 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id TAA09515 for hackers-outgoing; Sun, 26 Oct 1997 19:31:43 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from horst.bfd.com (horst.bfd.com [204.160.242.10]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id TAA09510 for ; Sun, 26 Oct 1997 19:31:41 -0800 (PST) (envelope-from ejs@bfd.com) Received: from harlie.bfd.com (bastion.bfd.com [204.160.242.14]) by horst.bfd.com (8.8.5/8.7.3) with SMTP id TAA23754; Sun, 26 Oct 1997 19:22:39 -0800 (PST) Date: Sun, 26 Oct 1997 19:22:39 -0800 (PST) From: "Eric J. Schwertfeger" 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: > > > Do you know anything of Richard Hamming's assertion that parity memory > > > (the old fashioned even/odd type) is-a-bad -thing in large > > > configurations? > > > > I think it bullshit. I've never heard of this before. Nor have you in > > the two times you've mentioned it, actually stated what is supposed to be > > so bad about it. > > more bits means more chance of error even if they are "error-correcting" > bits? No, ECC is fine, it's parity only that causes the problem. Basically, with non-parity memory, you have a higher chance of getting the right answer, but if you get the wrong answer, you might not know it. With ECC memory, the chances of getting the right answer go up quite a bit,