geff@iastate.edu (Underwood Geoffrey Dale) (12/05/90)
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 reliable than core was that most people can ignore the problem. > [possible implications of bad data deleted] Yes, data errors can occur. Bloody unlikely these days, but not 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. > If I seem paranoid in all the above, please consider that I've >been working with computers for a fairly long time (see what you have >to look forward to? :-) and no, to my knowledge nobody had used non- >parity memory for a long time before I started (that was in 1967) either. And you had to program uphill both ways with a piano on your back, in the burning sun and whipping snow... :) Seriously, I can understand the desire for parity memory when you're working with stone knives and bearskins. Parity memory only became a joke very recently. > > > 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! * >********************************************************************** Geff Underwood geff@iastate.edu PS: Please, followup _only_ to alt.religion.computers. This really has nothing to do with NeXT.
bennett@mp.cs.niu.edu (Scott Bennett) (12/06/90)
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! * **********************************************************************
geff@iastate.edu (Underwood Geoffrey Dale) (12/06/90)
In article <1990Dec5.233830.19865@mp.cs.niu.edu> bennett@mp.cs.niu.edu (Scott Bennett) writes: >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: >>> [a claim about the value of parity memory] >> [I dispute his claim.] > [He reiterates.] >> >>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*? I missed it because it wasn't there. The value of parity memory has no more significance on the NeXT than it does on any other machine. You are making a claim of the form "Any person who does not use computer technology X is a moron," which is the sort of thing alt.religion.computers was created to protect other newsgroups from. > 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! * >********************************************************************** Geff Underwood geff@iastate.edu
eps@toaster.SFSU.EDU (Eric P. Scott) (12/09/90)
In article <1990Dec6.155418.23293@news.iastate.edu> geff@iastate.edu (Underwood Geoffrey Dale) writes: > You are making a claim of the form "Any person who does not use >computer technology X is a moron," which is the sort of thing >alt.religion.computers was created to protect other newsgroups from. ...but comp.windows.x and its ilk reinforce... -=EPS=- -- NextStep(tm): the X terminator
garnett@cs.utexas.edu (John William Garnett) (12/21/90)
I'm not sure if the cost of using parity memory on a NeXT was
ever resolved. I just submitted a question to the local campus NeXT
representative and was informed that memory accesses to parity
memory (on a NeXT) cost an extra cycle (over that required by
non-parity memory). If this issue is important to you, you should
probably confirm (or hopefully invalidate) this news with NeXT before
purchasing parity memory.
--
John Garnett
University of Texas at Austin
garnett@cs.utexas.edu Department of Computer Science
Austin, Texascfw@aplpy.jhuapl.edu (Chuck Waltrip) (12/28/90)
In article <1038@tokio.cs.utexas.edu> garnett@cs.utexas.edu (John William Garnett) writes: >I'm not sure if the cost of using parity memory on a NeXT was >ever resolved. I just submitted a question to the local campus NeXT I'm not sure that there was ever an answer to the question about what NeXT OS does when a parity error is encountered...if anyone knows, I'd sure be interested in the answer (sorry if it was posted and I missed it). >representative and was informed that memory accesses to parity >memory (on a NeXT) cost an extra cycle (over that required by >non-parity memory). If this issue is important to you, you should I don't know the answer either but I believe this cost may not be terribly significant if you're running with a high cache hit rate. >probably confirm (or hopefully invalidate) this news with NeXT before >purchasing parity memory. > >-- >John Garnett > University of Texas at Austin >garnett@cs.utexas.edu Department of Computer Science > Austin, Texas c.f.waltrip <cfw@aplpy.jhuapl.edu> Opinions expressed are my own.