Xref: utzoo comp.sys.next:18365 comp.arch:23053
Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!wuarchive!udel!haven.umd.edu!umbc3.umbc.edu!umbc4.umbc.edu!brian
From: brian@umbc4.umbc.edu (Brian Cuthie)
Newsgroups: comp.sys.next,comp.arch
Subject: Re: parity is for farmers?
Message-ID: <1991Jun3.134917.12326@umbc3.umbc.edu>
Date: 3 Jun 91 13:49:17 GMT
References: <1991May21.232331.24888@cs.umn.edu> <1991Jun03.040242.15406@ariel.unm.edu>
Sender: newspost@umbc3.umbc.edu (News  posting account)
Distribution: na
Organization: Univ. of Maryland Baltimore County, Academic Computing Services
Lines: 32

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...

What!? Are you kidding ?  Maybe instead it changes the amount of a deposit 
while I am balancing my checkbook.  Bit errors are as unpredictable in 
location as they are in frequency.  Therefore, it is not reasonable to
make any assumptions concerning their effects.

>2) I don't know about the NeXT, but the Amiga used to also store checksums
>   at the end of the file stored in RAM. Everytime in went to run the program
>   it would calculate the checksum and compare it to the stored one, if they
>   didn't match, it'd give you a dialog box saying so. I ONLY had that problem
>   when I was using this nifty utility that would compress programs, which
>   would automagically decompress in RAM--the checksums didn't match cuz one
>   was compressed, and the other wasn't!

Well I can say with some certainty that the NeXT (or Mach, for that  matter)
doesn't run around doing checksums of things in memory.  That would cost
*way* too much time.  It's easy to do at program launch time, but in the
context of a running program's data area, it would be necessary to recompute
and store the checksum *each time something was knowingly changed*.  Not
feasible.

Unfortunately, although not without it's onw problems, parity is the only
cost effective way of adding some detection mechanism for bit errors in
memory.  Of course, it still doesn't help you if you mangle your data
yourself :-)

-brian