Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!julius.cs.uiuc.edu!ux1.cso.uiuc.edu!mp.cs.niu.edu!bennett
From: bennett@mp.cs.niu.edu (Scott Bennett)
Newsgroups: comp.sys.next
Subject: Re: parity memory
Keywords: parity, data integrity, ECC
Message-ID: <1990Dec5.233830.19865@mp.cs.niu.edu>
Date: 5 Dec 90 23:38:30 GMT
References: <1990Dec4.032737.12258@engin.umich.edu> <1990Dec5.005831.30208@mp.cs.niu.edu> <1990Dec5.140619.7948@news.iastate.edu>
Distribution: na
Organization: Northern Illinois University
Lines: 71

In article <1990Dec5.140619.7948@news.iastate.edu> geff@iastate.edu (Underwood Geoffrey Dale) writes:
>In article <1990Dec5.005831.30208@mp.cs.niu.edu>,
>	bennett@mp.cs.niu.edu (Scott Bennett) writes:
>>     Here we go again.  (sigh)  If you don't have parity memory, you 
>>don't have any way of knowing whether what was written to memory last
>>will be the same thing read back later.
>	If you do have parity memory, you still don't have any way of
>_knowing_ whether what was written to memory last will be the same thing
>read back later.  Your odds have increased, but two-bit errors will
>_still_ get you.  Parity memory gives a false sense of security.  If you
>really need more assurance of data integrity than regular backups can
>give, you need ECC memory.  Besides, silicon memory is so much more

     Well, of course.  ECC systems depend upon the presence of a parity
bit.  ECC is indeed preferable, but without at least parity you really
have little or nothing to go on when you have to find out why your
computer is turning senile.  In other words, more error detection and
some error correction are even better than just some error detection.
*No* error detection means you have nothing in your favor when a chip
is going bad.

>reliable than core was that most people can ignore the problem.

     All you are saying is that data and system integrity are not a
critical need in your own use of computers.  It is unfair of you to
assume that everybody else's use of computers is similarly needless.
My posting did allow for your situation.
>
>> [possible implications of bad data deleted]
>	Yes, data errors can occur.  Bloody unlikely these days, but not

     I see bad memory being replaced around here plenty frequently
enough, but at least it isn't so primitive that we don't know what has
gone bad.

>impossible.  Of course, they can still occur even with parity memory, or
>even with _perfect_ memory -- disks can go bad, too.  Parity memory does
>_not_ magically assure you of data integrity.

     That is correct.  I see disks being replaced, too.  We rarely
suffer significant loss or corruption of data because the hardware
is not made from "bearskins and stone knives" like memory that doesn't
even have parity.
>
>>     If I seem paranoid in all the above, please consider that I've
>>  [text deleted  -SJB]
>>**********************************************************************
>
>		Geff Underwood
>		geff@iastate.edu
>
>PS:  Please, followup _only_ to alt.religion.computers.  This really has
>nothing to do with NeXT.

     It has everything to do with NeXT.  How on earth could you have
missed *that*?  The NeXT 68030 cubes come with 1MBx8 SIMMs.  The default
configuration of NeXT's 68040 machines apparently is with 1MBx8 SIMMs.
No hardware error detection, much less correction.


                                  Scott Bennett, Comm. ASMELG, CFIAG
                                  Systems Programming
                                  Northern Illinois University
                                  DeKalb, Illinois 60115
**********************************************************************
* Internet:       bennett@cs.niu.edu                                 *
* BITNET:         A01SJB1@NIU                                        *
*--------------------------------------------------------------------*
*  Visit the scenic Illinois Craters!  Just 10 minutes               *
*  from New Chicago!                                                 *
**********************************************************************