From owner-freebsd-hackers Tue Oct 28 18:57:00 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id SAA13381 for hackers-outgoing; Tue, 28 Oct 1997 18:57:00 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from dragon.awen.com (dragon.awen.com [207.33.155.10]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id SAA13375 for ; Tue, 28 Oct 1997 18:56:58 -0800 (PST) (envelope-from mburgett@dragon.awen.com) Received: (from mburgett@localhost) by dragon.awen.com (8.8.7/8.8.7) id SAA18297; Tue, 28 Oct 1997 18:56:54 -0800 (PST) Message-Id: <199710290256.SAA18297@dragon.awen.com> From: "Mike Burgett" To: "dg@root.com" Cc: "hackers@FreeBSD.ORG" Date: Tue, 28 Oct 97 18:56:54 -0800 Reply-To: "Mike Burgett" Priority: Normal X-Mailer: PMMail 1.92 For OS/2 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: Re: Parity Ram Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Tue, 28 Oct 1997 17:29:28 -0800, David Greenman wrote: >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. Ummm. Hmmmm. Doesn't the memory subsystem interact with the L2 cache on a per-line basis anyway? IOW, a cache line is read in anytime a byte is accessed, and when it's time to write, the line is either dirty, or it isn't, and if it is, the whole thing is burst back to memory anyway... I thought the (slight) performance penalty was to allow a clock or two for the new ECC to be calculated, not because a write occurred. Then again, maybe it's just me. :) (Or maybe the PC is different from other hardware I've been more intimate with...) --Mike