From owner-freebsd-hardware  Tue Feb 18 06:59:08 1997
Return-Path: <owner-hardware>
Received: (from root@localhost)
          by freefall.freebsd.org (8.8.5/8.8.5) id GAA08078
          for hardware-outgoing; Tue, 18 Feb 1997 06:59:08 -0800 (PST)
Received: from bunyip.cc.uq.edu.au (daemon@bunyip.cc.uq.edu.au [130.102.2.1])
          by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id GAA08065
          for <freebsd-hardware@freebsd.org>; Tue, 18 Feb 1997 06:59:03 -0800 (PST)
Received: (from daemon@localhost)
	by bunyip.cc.uq.edu.au (8.8.5/8.8.5) id AAA19174;
	Wed, 19 Feb 1997 00:58:48 +1000
Received: by ogre.devetir.qld.gov.au (8.7.5/DEVETIR-E0.3a)
	id WAA12652; Tue, 18 Feb 1997 22:01:24 +1000 (EST)
Date: Tue, 18 Feb 1997 22:01:24 +1000 (EST)
From: Stephen McKay <syssgm@devetir.qld.gov.au>
Message-Id: <199702181201.WAA12652@ogre.devetir.qld.gov.au>
To: asami@vader.cs.berkeley.edu (Satoshi Asami)
cc: freebsd-hardware@freebsd.org, syssgm@devetir.qld.gov.au
Subject: Re: 64 MB ECC or 128 MB non ECC ?
X-Newsreader: NN version 6.5.0 #1 (NOV)
Sender: owner-hardware@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk

asami@vader.cs.berkeley.edu (Satoshi Asami) wrote:

> * Well, I'm glad I've got some cache to enable since without cache the kernel
> * compile takes 15 times as long.  Yes, my ECC, nocache test took 97 minutes!
> * Yikes!  The final result is that ECC is 12% slower than PARITY with no cache.
> * (user+sys time only).  This is in agreement with those people who predicted
> * 10-15% main memory slow down, but, as noted above, reduces to 1% with both
>
>Thanks for verifying it.

I've found out something new that means that what I've "verified" might not
be what you thought I was verifying.  Intel's TXC documentation states that
you have to reduce your read accesses to x333 if using ECC.  (There is a
one clock lead-off penalty too.)  Since I'm already running my FPM at x333
there would be (next to) no penalty there.  Only EDO users would suffer.
Looks like the read-modify-write penalty (as mitigated by the TXC write
reassembly buffers) was what I was really measuring.

> * caches enabled.  1% is no pain at all.
>
>Well that depends, if you are X-user-switch-around-between-20-windows
>type of guy, you can actually feel the 10% slowdown as you use the
>machine.  I switched back to parity because I couldn't stand it. ;)

Hmm.  I beat my machines until they beg for mercy. :-)  I haven't run X on
the new box yet as I'm still experimenting with weird stuff (like old SCSI
disks that lock up the SCSI bus), and I can't afford a second good monitor.
If I never run it for real without ECC, I'll never know what I'm missing. :-)

Stephen.