Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!samsung!uunet!crdgw1!crdos1!davidsen
From: davidsen@crdos1.crd.ge.COM (Wm E Davidsen Jr)
Newsgroups: comp.arch
Subject: Re: Workstation Data Integrity
Message-ID: <2469@crdos1.crd.ge.COM>
Date: 28 Aug 90 18:11:11 GMT
References: <1990Aug3.204358.330@portia.Stanford.EDU> <40694@mips.mips.COM> <2399@crdos1.crd.ge.COM> <1990Aug10.171744.9639@zoo.toronto.edu> <2421@crdos1.crd.ge.COM> <1990Aug18.210132.25203@sco.COM> <2434@crdos1.crd.ge.COM> <6797.26d6edce@vax1.tcd.ie>
Reply-To: davidsen@crdos1.crd.ge.com (bill davidsen)
Organization: GE Corp R&D Center, Schenectady NY
Lines: 58

In article <6797.26d6edce@vax1.tcd.ie> rwallace@vax1.tcd.ie writes:

|                                             Consider: suppose a parity error
| occurs on a 640K machine. The error is probably in either an unused area of
| memory (e.g. at the DOS prompt) or in a section of code that isn't going to be
| executed on this session with the program (e.g. error handling code). (I'm
| talking only about transient errors here: the boot time memory check will get
| other kinds). So ignoring the parity error will probably have no effect.

  You may be the only DOS user on the planet who has any bits unused.

|                                           OK take the very unlikely case that
| it is in your data. For me that means in the source for a program I'm writing.
| This is no problem, I can just fix the one trashed character when the compiler
| barfs on the code. 

  One bit changes 0 to 1, + to *, etc. Your compiler catches this?

|                    Much better than having the machine crash and lose several
| minutes' work. Or say the error is in a floating-point number in a spreadsheet.
| Chances are the program will crash with a floating-point error or at least
| produce obviously wrong results e.g. profit for 1989 was $-32198742.88888.
| 
| The point is that ignoring a parity error is a pretty safe thing to do; there's
| very little chance of getting a misleading answer.

  A little though should show you the error of that thought. Over half
the word is dedicated to less significant bits of the mantissa. An error
in any of those bits will result in a percent or less change.

|                                                    Much better than crashing
| the computer, which is guaranteed to lose you whatever you had in memory.

  Exactly. No answer is better than a wrong answer. What would anyone
bother to run on a computer which is so valueless that they don't care
if they get a right answer, just so that you get an answer? If that's
the case, why not make one up?

| (Suppose you have a parity error while running a Speed Disk program: kiss your
| hard disk goodbye. Let's see, when did I do my last full backup?). So the PC
| parity protection is worse than useless.

  In the first place, anyone who runs a program like that without
running a backup first is really careless with their data. To quote my
old sig "stupidity, like virtue, is its own reward." And if you have an
error and *don't* catch it, you can blindly read in all the data on the
disk, corrupt it, and rewrite it wrong. Is this better? A good disk
packer will only lose a portion of the data on a crash, and it will be
gone, not corrupted. A parity error will corrupt the data.

  I have worked with systems which didn't have parity, and I hated it. I
don't have anything my system I don't need, so I care about all of it.
While my data doesn't represent a threat to someone's life if it's
wrong, it could be a threat to my income. That's important enough for
me.
-- 
bill davidsen	(davidsen@crdos1.crd.GE.COM -or- uunet!crdgw1!crdos1!davidsen)
    VMS is a text-only adventure game. If you win you can use unix.