Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!magnus.acs.ohio-state.edu!cis.ohio-state.edu!ucbvax!pasteur!cory.Berkeley.EDU!navas From: navas@cory.Berkeley.EDU (David C. Navas) Newsgroups: comp.sys.amiga.advocacy Subject: Re: Why are Amigaoids hell bent on proving the Amiga is better ? Message-ID: <14346@pasteur.Berkeley.EDU> Date: 30 Jun 91 22:07:57 GMT References: <1991Jun29.005127.17803@grebyn.com> <1991Jun29.150321.9791@NCoast.ORG> <1991Jun30.203110.29358@unhd.unh.edu> Sender: news@pasteur.Berkeley.EDU Reply-To: navas@cory.Berkeley.EDU Lines: 69 In article <1991Jun30.203110.29358@unhd.unh.edu> pss1@kepler.unh.edu (Paul S Secinaro) writes: >I can't comment on the particular parity scheme used in the PC >architecture, but I think you are confusing "reliability" with "system >availability". What parity does is to give extra assurance that the >data you just recieved is good data. If there is even the slightest >chance that the data is bad, you want to know about it. If this means Okay, fine. But you'll never use a processor much more complex than a '286. You see, there's no good way of "proving" whether the newer '486 or '040s actually had "working" masks. Go figure. >Take the space shuttle, for example. You have something like five >computers all simultaneously operating on the same input and hopefully >producing the same output. This means that, if all the computers give Except that the space shuttle is just a little different, ya'know? Computers here on earth do not need to work flawlessly at G forces between 0 and 3, aren't running some 3-5 million lines of assembly, and don't have to survive Van Allen belts. Do people still not understand the exponential nature of system complexity? >is actually smaller than X. You tradeoff system availability for data >integrity. It's the same idea with parity. Many sites keep plenty of No, I don't think so. If the computers on the shuttle didn't work, we get another disaster. NOT! As I recall they use slightly different algorithms for decision making, and the majority decision wins. It's like a version of ECC. IE. errors are *corrected*, it's the only thing that really makes sense. Your analysis of error rates is only useful for "serial" systems where *ALL* systems must work at the same time. If we get three harddrive systems with a controller which takes a "majority wins" attitude your MTFB rises significantly (because two harddrives would have to fail at exactly the same time in exactly the same way, which is _less_ likely). Or am I missing something? >bad RAM chip spitting out bad data all over the company (you can >imagine the havoc this might cause in, say, an accounting program, or >an important engineering design application). No, they'd rather ignore the problem. People routinely have to *prove* the necessity of bothering repair personnal. Horror stories on demand. >On the other hand, as you mention, RAM errors are really pretty rare, >and for personal or light business use, I wouldn't worry too >much about how much error detection/correction my computer had. It's meaningless until we start using a lot more memory. The CPU is a better source of error, I would bet. Certainly I've had my power supply blow more frequently than my memory. >P.S. BTW, speaking of ECC RAM, I think the DECstations use it, but >judging from DEC's prices for add-ons, I'll bet it's big bucks :-). The new 6000 systems actually has a great deal of ECC stuff in it. At least from a talk given on it I was given that impression. Memory, datapath, and CPU all have ECC checking. Cool stuff. Doesn't matter much, we agree that parity is probably pretty meaningless for memory nowadays. Some folks think that its a way to sell computers to businessPEOPLE (ahem :) ). I'll bet the majority of businessfolks haven't a clue to what parity is. The defense dep't is a different story.... David Navas navas@cory.berkeley.edu 2.0 :: "You can't have your cake and eat it too." Also try c186br@holden, c260-ay@ara and c184-ap@torus