Date: Wed, 22 May 1996 09:47:13 -0500 (CDT) From: Joe Greco <jgreco@brasil.moneng.mei.com> To: dave@persprog.com (David Alderman) Cc: hardware@freebsd.org Subject: Re: Triton chipset with 256k cache caches 32M only? Message-ID: <199605221447.JAA23075@brasil.moneng.mei.com> In-Reply-To: <1E75A1F6F@novell.persprog.com> from "David Alderman" at May 20, 96 01:27:21 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> > 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199605221447.JAA23075>