From owner-freebsd-hackers Tue Oct 28 18:26:15 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id SAA11486 for hackers-outgoing; Tue, 28 Oct 1997 18:26:15 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from implode.root.com (implode.root.com [198.145.90.17]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id SAA11479 for ; Tue, 28 Oct 1997 18:26:10 -0800 (PST) (envelope-from root@implode.root.com) Received: from implode.root.com (localhost [127.0.0.1]) by implode.root.com (8.8.5/8.8.5) with ESMTP id SAA20846; Tue, 28 Oct 1997 18:27:42 -0800 (PST) Message-Id: <199710290227.SAA20846@implode.root.com> To: Mikael Karpberg cc: hackers@FreeBSD.ORG Subject: Re: Parity Ram In-reply-to: Your message of "Wed, 29 Oct 1997 03:29:12 +0100." <199710290229.DAA07708@ocean.campus.luth.se> From: David Greenman Reply-To: dg@root.com Date: Tue, 28 Oct 1997 18:27:42 -0800 Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >> In order to update the memory, the ECC must be recalculated over the >> entire 64bit quadword. This escentially means that you have to read the >> memory first, apply the changes/calculate the new ECC and then write it >> back. Obviously,this makes memory writes quite a bit slower. > >Hmm... It's still not quite clear to me. That is, does this slow my >computer down, in case I use ECC? Yes. >It seems to me all this could be done on the DIMM/SIMM, or something, >possibly clocked at multiple of the bus clockspeed, and therefor >not effect the rate at which memory could be read/written over the bus >by the CPU. It may seem that way, but it isn't. :-) >If that's not the case, and the computer is actually slowed down by ECC, >how much performace do you loose? 0.1%? 5%? 30%? Probably less than 5%, but it will depend on the application. -DG David Greenman Core-team/Principal Architect, The FreeBSD Project