Xref: utzoo comp.sys.next:18392 comp.arch:23061
Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!wuarchive!udel!princeton!taylor!ssr
From: ssr@taylor.Princeton.EDU (Steve S. Roy)
Newsgroups: comp.sys.next,comp.arch
Subject: Re: parity is for farmers?
Message-ID: <10350@idunno.Princeton.EDU>
Date: 3 Jun 91 16:02:57 GMT
References: <1991May21.232331.24888@cs.umn.edu> <1991Jun03.040242.15406@ariel.unm.edu>
Sender: news@idunno.Princeton.EDU
Followup-To: comp.sys.next
Distribution: na
Organization: Princeton University
Lines: 29

In article <1991Jun03.040242.15406@ariel.unm.edu> ratshana@triton.unm.edu (R.L.) writes:
>Parity memory isn't really necessary for two reasons:
>1) Unless you buy really cheap memory, you should NEVER have a problem with
>   screwed up RAM. Besides, if the RAM is screwy, whats the worst that can
>   happen? Your term window dies, so you kill it on another task...

I'm sorry but this is an awfully glib statement and should come with a
bunch of qualifiers like that cluster around a particular theme.

    if you do a given calculation many times and can compare the
results to see if something is wrong.  This includes being able redo a
compile or something similar.

    if you are operating far from the limits of the machine.  This
means that you will be able to rerun the job.

    if you don't really care whether a given calculation was correct.
The vast majority of the memory in many (especially scientific) codes
is in large arrays of floating point numbers and if a bit flips
somewhere in there it will not crash the program it will just give
wrong answers.

Now, I realize that these things are typically true for the majority
of the readers of this group, code hackers for whom most of the
burdens on the machine come from editing and the occasional compile.
There are, however, many users for whom these things are not true and
it bugs me to see glib generalizations like the above.  

Steve Roy.