Path: utzoo!attcan!uunet!tut.cis.ohio-state.edu!pt.cs.cmu.edu!gandalf.cs.cmu.edu!lindsay
From: lindsay@gandalf.cs.cmu.edu (Donald Lindsay)
Newsgroups: comp.arch
Subject: Re: Workstation Data Integrity
Summary: parity is a Good Thing
Message-ID: <10397@pt.cs.cmu.edu>
Date: 5 Sep 90 20:49:28 GMT
References: <6797.26d6edce@vax1.tcd.ie> <56qmo1w162w@zl2tnm.gp.govt.nz> <19875@crg5.UUCP> <19208@dime.cs.umass.edu> <2201@lectroid.sw.stratus.com> <68362@sgi.sgi.com> <1990Sep4.163619.24726@zoo.toronto.edu> <68505@sgi.sgi.com> <2483@crdos1.crd.ge.COM> <2361@cirrusl.U
Organization: Carnegie-Mellon University, CS/RI
Lines: 20

In article <2361@cirrusl.UUCP> douglas%cirrusl@oliveb.ATC.olivetti.com 
	(Douglas Lee) writes:
>DRAM manufactures express reliablity in terms of FITs (Failures In
>Time). ... The FIT rate really only measures errors due to
>alpha particle radiation. There can be more soft errors caused by
>power supply spikes, drop outs, etc. that have not been accounted for
>here.

Yes. Also, note that parity/ECC may catch problems with connectors,
bus drivers, fans and filters (== overheating), system environment,
and so on.  Further, FIT MTBF is an average.  There are always
machines "built on a Monday", just as with cars.  

It doesn't contribute much to this discussion to give anecdotal
evidence of zero parity errors.  Others of us have anecdotes to the
contrary.  For example, my workstation has had errors in its frame
buffer - which isn't parity protected, because the occasional extra
pixel isn't too important.  I just refresh the screen. 
-- 
Don		D.C.Lindsay