From owner-freebsd-hardware Thu May 16 18:53:45 1996 Return-Path: owner-hardware Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id SAA26979 for hardware-outgoing; Thu, 16 May 1996 18:53:45 -0700 (PDT) Received: from pegasus.com (pegasus.com [140.174.243.13]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id SAA26969; Thu, 16 May 1996 18:53:41 -0700 (PDT) Received: by pegasus.com (8.6.8/PEGASUS-2.2) id PAA20303; Thu, 16 May 1996 15:51:28 -1000 Date: Thu, 16 May 1996 15:51:28 -1000 From: richard@pegasus.com (Richard Foulk) Message-Id: <199605170151.PAA20303@pegasus.com> In-Reply-To: "Rodney W. Grimes" "Re: Triton chipset with 256k cache caches 32M only?" (May 15, 10:04am) X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: "Rodney W. Grimes" , jgreco@brasil.moneng.mei.com (Joe Greco) Subject: Re: Triton chipset with 256k cache caches 32M only? Cc: hackers@freebsd.org, hardware@freebsd.org Sender: owner-hardware@freebsd.org X-Loop: FreeBSD.org Precedence: bulk } > > >> No, it uses the parity bits. Only 8 syndrome bits are needed } > > >> for 64bit words. } > > > } > > > Hmm. So does that mean the ECC is limited to single (odd } > > >number of) bit errors? } > > } > > ECC has single bit error correction and 2 bit error detection. Better than } > > parity no matter how you slice it. } } Only if you have memory that is failing or you need extreamly reliable } operation (good memory should have a single bit error rate of something } like 1 in 10 years). This is all subject to personal judgement. How a 15% performance hit compares with the possibility of lost or bad data should not be trivialized. One error in ten years may not seem like much, but it could still cost lots of time and money. And it's just as likely to happen today as in ten years. Besides, parity protection doesn't prevent memory-error crashes, ECC does. Having no protection is scarey (Triton-I). Parity memory is a great improvement. ECC is better yet. Richard