From owner-freebsd-hardware Wed May 22 07:47:50 1996 Return-Path: owner-hardware Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id HAA01184 for hardware-outgoing; Wed, 22 May 1996 07:47:50 -0700 (PDT) Received: from brasil.moneng.mei.com (brasil.moneng.mei.com [151.186.109.160]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id HAA01178 for ; Wed, 22 May 1996 07:47:48 -0700 (PDT) Received: (from jgreco@localhost) by brasil.moneng.mei.com (8.7.Beta.1/8.7.Beta.1) id JAA23075; Wed, 22 May 1996 09:47:13 -0500 From: Joe Greco Message-Id: <199605221447.JAA23075@brasil.moneng.mei.com> Subject: Re: Triton chipset with 256k cache caches 32M only? To: dave@persprog.com (David Alderman) Date: Wed, 22 May 1996 09:47:13 -0500 (CDT) Cc: hardware@freebsd.org In-Reply-To: <1E75A1F6F@novell.persprog.com> from "David Alderman" at May 20, 96 01:27:21 pm X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: owner-hardware@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > > Obviously it is a matter of how paranoid (or silly?) you want to be.. I am > > perfectly confident that my disks will puke before my RAM. > > > > ... Joe > > > > You may be right about ECC. The loss of parity in the Triton I > should not be underestimated because of the potential for disaster at > the time the machine is first put into service. Absolutely! :-/ > A few years back, we put a Unix box into service which had DTC > caching disk controller in it. Although the controller did a RAM > test on power up, it did not even make use of the parity bit on the > RAM that was installed. It took a few weeks of service before someone > discovered the little bit errors showing up in their data. Since the > backup was on the same controller, you can guess how reliable they > were. It took quite a while to restore the data integrity on this > system, even with the original backups that were uncorrupted by the > controller (a lot of data can be generated in a few weeks on a > server!). I wish the computer had crashed! It would have saved a > lot of time and effort. Yeah, I hear you there :-( And adding parity checking really isn't that hard.. > I think Intel did a real disservice by ever producing a chipset that > did not check parity. I know that Triton chipset motherboards are > being used as servers, and that even a rigorous burnin may not > reveal some forms of memory failure that occur in a 32 bit operating > system under the stresses of real usage. At least with parity, the > machine did go down and the administrator was alerted to the problem > but nothing is worse than gradual data corruption. > > Maybe Intel is overcompensating a bit by giving us the option of ECC, > but anyone who was burned in the Triton I era might want that option. > Will I use it? I don't know, but I am glad it is there. Me too. :-) >From a practicality point of view, I understand producing a chipset with an _option_ to disable parity. Many consumer grade PC's are more interested in cheapness than reliability. Putting 32 bit memory in a consumer grade PC is an obvious cost optimization. ;-) However, any site wanting a server class system should be extremely interested in the ability to detect errors, even if the cost is substantially more than 9/8 the cost of non-parity RAM (as the current market seems to be). The easy way to tell the men from the boys is who's running FreeBSD on a hot PCI board with parity RAM ;-) I even buy parity RAM for non-parity boards, because I assume I will replace the board someday ;-) Now, the nifty thing about ECC is that while you would not want to use it on a daily basis, if something does happen (bad RAM with a few single bit errors, etc), you may be able to coax the system into running long enough to obtain replacements. Sometimes that is important. ;-) ... JG