Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!think.com!mintaka!ogicse!pdxgate!eecs!berggren
From: berggren@eecs.cs.pdx.edu (Eric Berggren)
Newsgroups: comp.sys.ibm.pc.hardware
Subject: Re: Memory Parity. Is It Really Needed
Message-ID: <2258@pdxgate.UUCP>
Date: 6 Apr 91 22:33:34 GMT
Article-I.D.: pdxgate.2258
References: <3370017@hpsgwp.sgp.hp.com> <1991Mar24.094904.9519@eecs.wsu.edu> <2217@pdxgate.UUCP> <1865@svin02.info.win.tue.nl>
Sender: news@pdxgate.UUCP
Lines: 44

wsineel@wsooti01.info.win.tue.nl (Eelco Vriezekolk) writes:

>In article <2217@pdxgate.UUCP> berggren@eecs.cs.pdx.edu (Eric Berggren) writes:
>>wbonner@eecs.wsu.edu (Wim Bonner) writes:
>>                                                        nice touch ;) -v
>>>In article <3370017@hpsgwp.sgp.hp.com> plim@hpsgwp.sgp.hp.com (Peter Lim) writes:
>[PC with and without memory parity]
>>
>>  The part about memory parity I don't understand is that I am told one
>>wants memory parity checking done to "prevent loss of important data". Well
>>everytime I got a memory parity error, I lost important data because it
>>brought the whole system to a halt. What next? Helicopters with emergency
>>ejector seats? wierd...

>In professional situations it could be much more important
>that you get *reliable* data than that you get data at all. If I
>did my financial administration on a PC (making regular
>backups, ofcourse) I'd prefer a total crash to some errors
>slipping into the database.
>That's the point for memory parity checking. It is the same
>reason as why you do write-verify on disks, only these kinds
>of errors are more easily recoverable.

>`Fault tolerance' consists of both interception of errors
>(very important) and automatic recovery of errors (very
>useful).


  I agree, but I would rather be advised and allow me to make a decision
about how I would handle it. In some databases (and probably some spread-
sheets too) if you don't close up properly, you may lose everything. Of
course, that's what backups are for. When a write-verify fails on a disk,
it doesn't erase the disk for you. It gives you an error and, depending,
on the application, allows you to use another disk.
  My main point was not necessarily the concept of memory parity (which
I probably left the subject a little) but more how most systems handle it.
Anyway, no big deal. It doesn't happen that often... <splat>

-e.b.

==============================================================================
  Eric Berggren             |  "The force of the 'Dark Side' eminates from 
  Computer Science/Eng.     |    the ominous DeathStar looming overhead." 
  berggren@eecs.cs.pdx.edu  |            - Down with AT&T! -