saf@moss.ATT.COM (10/14/87)
Has anyone noticed that most SIMMs have 8 chips and a very few have 9? The obvious implication is that Apple doesn't believe in parity as a means for detecting errors. It would seem that particularly with 1 megabit DRAMS, the probability of soft errors will start to become significant. If the Macs are targetted at commercial users as well as the home market, then some robustness ought to be designed in. I would hate to trust these beasts with tens of thousands of dollars worth of data with no indication that it was corrupted (other than La Bomba :-). Opinions? Anybody know if "no parity" holds true for the Mac II? Steve Falco moss!saf saf@moss.ATT.COM
steele@unc.cs.unc.edu (Oliver Steele) (10/16/87)
saf@moss.ATT.COM writes: >Has anyone noticed that most SIMMs have 8 chips and a very few have 9? The >obvious implication is that Apple doesn't believe in parity as a means for >detecting errors. It would seem that particularly with 1 megabit DRAMS, the >probability of soft errors will start to become significant. If the Macs are >targetted at commercial users as well as the home market, then some >robustness ought to be designed in. Keep in mind that the circuitry for parity error detection is more complicated, and, of course, requires a higher chip count. This means that your system may detect errors more frequently, but that it will be more error prone as well. As long as your memory problems aren't intermittent a single test at boot time works better, and this is exactly what Apple has. (This should spark some debate :-) ------------------------------------------------------------------------------ Oliver Steele ...!{decvax,ihnp4}!mcnc!unc!steele steele%unc@mcnc.org "'As it were' means 'I think that I sound very erudite.' 'Per se' is Latin for 'as it were.' As it were."
gnome@oliveb.UUCP (Gary) (10/16/87)
> .... I would hate to trust these beasts with > tens of thousands of dollars worth of data with no indication that it was > corrupted (other than La Bomba :-). > > Opinions? Anybody know if "no parity" holds true for the Mac II? > Steve Falco moss!saf saf@moss.ATT.COM Parity is pretty useless in the IBM-PC marketplace, where it exists more as a data-sheet compatibility issue than a technical one. After all, when the system detects a parity error, it just halts. (Wow, how useful -- it doesn't close files, or in the case of UNIX on the PC, a SYNC) So, if you want a system that is super-reliable, design-in ECC and software that verifies bus/IO transactions. There are a bunch of hardware/software safeguards that can be designed into medical/financial computers, but each additional feature increases the price a little and is not very high on most users priorities. It wouldn't be hard to make a "secure Mac" -- but then, how do you guard against bad code? Gary
cantrell@alliant.Alliant.COM (Paul Cantrell) (10/26/87)
Steve Falco stated that he would not like to trust Apple computers with large sums of money, because of the lack of parity. Then In article <7118@oliveb.UUCP> gnome@oliveb.UUCP (Gary) writes: >Parity is pretty useless in the IBM-PC marketplace, where it exists >more as a data-sheet compatibility issue than a technical one. >After all, when the system detects a parity error, it just halts. >(Wow, how useful -- it doesn't close files, or in the case of UNIX >on the PC, a SYNC) > >So, if you want a system that is super-reliable, design-in ECC and >software that verifies bus/IO transactions. > >There are a bunch of hardware/software safeguards that can be >designed into medical/financial computers, but each additional >feature increases the price a little and is not very high on most >users priorities. > >It wouldn't be hard to make a "secure Mac" -- but then, how do you >guard against bad code? > >Gary Sorry 'Gary', but I have to agree with Steve Falco about this. In my mind, it is a real shortcoming that the Mac lacks main memory parity. This was probably a reasonable decision for Apple to make on early computers like the Apple II which had small amounts of memory, and was not (often) being used to run nuclear reactors. However, as people begin to use the Mac for engineering and financial purposes, and as memories get larger and larger, I believe it is important for the main memory system to have some checking built in. Note that I don't think the Mac needs ECC memory as Gary suggested. I don't want a super-reliable Mac that can keep running with half the hardware smoked out. What I DO want to see is a Mac that detects that a memory error has occurred, rather than one that may continue to run, cranking out possibly erroneous results. At least if the system detects a parity error and bombs, I know I have a problem to look into. An example would be an engineer using his user-friendly MacStress program to design a bridge. A memory error in the current system might cause a bug that would crash the Mac, or it might just alter some data in a way which does NOT cause the Mac to bomb, but DOES cause the bridge to fall down. People could be killed (or huge sums of money lost) because Apple saved $50 on a $7,000 Mac II engineering system. I'm sure readers of comp.risks could tell us of other hardware (and software) failures which can cause large loss of life or money if results of computer programs are believed without any cross checking for reasonableness, however I think Apple is missing the boat by not trying to detect one of the more common hardware failures. PC
dennisg@pwcs.UUCP (10/28/87)
Just to add to this ( slightly ) I will state that parity memory would be both a waste of time and money. ECC is MUCH more effective but would definitely slow things down and $$COST$$ a lot more. Just test it at boot time... -- Dennis Grittner City of Saint Paul, Minnesota (612) 298-4402 Room 700, 25 W. 4th St. 55102 "Let's just put Ollie, Ronnie, and the rest in jail!"