Path: utzoo!utgpu!news-server.csri.toronto.edu!bonnie.concordia.ca!uunet!unhd.unh.edu!kepler.unh.edu!pss1 From: pss1@kepler.unh.edu (Paul S Secinaro) Newsgroups: comp.sys.amiga.advocacy Subject: Re: Why are Amigaoids hell bent on proving the Amiga is better ? Message-ID: <1991Jun30.203110.29358@unhd.unh.edu> Date: 30 Jun 91 20:31:10 GMT References: <1991Jun29.005127.17803@grebyn.com> <1991Jun29.150321.9791@NCoast.ORG> Sender: usenet@unhd.unh.edu (USENET News System) Organization: University of New Hampshire Lines: 66 Nntp-Posting-Host: kepler.unh.edu In article <1991Jun29.150321.9791@NCoast.ORG> davewt@NCoast.ORG (David Wright) writes: >In article <1991Jun29.005127.17803@grebyn.com> ckp@grebyn.com (Checkpoint Technologies) writes: >>In article greg@pfloyd.lonestar.org (Greg Harp) writes: >>>I have always had a bit of a beef with this one. What the *hell* kind of >>>good does 1 parity bit do you? >>It does exactly one bit more good than no bits. :-) > No, actually it is WORSE, at least in the brain-dead way that IBM >clones use it. If you have 1 bit out of 9 for parity, with no error correction, >that means that more than 10% of the time the error will be in the parity >bit itself. Since PC clones are not designed to have any ECC bits, and the >whole parity detection system is incredibly archaic, a parity error just brings >the whole machine to a halt, even when it is in the parity bit itself. > I cetainly call this "less reliable", since you have now added a >"feature" that will cause the computer to seemingly "fail" over 10% more than >it normally would. > Further, the PC is too brain-dead to even see where the address is, >and whether it is in use. A parity error outside of active memory should, >at the most, pop up a requestor notifying you it occured, without halting the >system at all (oops, PC don't have multitasking). > I have been working with PC's since the first IBM "PC" (not even XT) >came out, and in ALL THAT TIME, I have only seen 2, thats *TWO* parity >errors. Both of which were over 6 years ago. And they occured on fairly >low-quality RAM boards at that. So what this means is that all PC clone >owners, whether they would want it or not, have been force to buy over >10% more RAM than they need, for a "feature" that was at best only crudely >implemented, and which increases the posibility of false "errors" and MTBF >by over 10%. Great deal there. > 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 you sometimes have to throw away good data, or the system is down a little more frequently, that's fine. What you are really interested in, in many applications, is being assured the answer is correct. 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 you the same answer, you are pretty sure it's the right answer. But if you go through the statistical calculations, you can show that, if the MTBF of each computer is X, the overall MTBF of the entire system is actually smaller than X. You tradeoff system availability for data integrity. It's the same idea with parity. Many sites keep plenty of spare parts (or whole computers) on hand. They would much rather take a system down for a few days and check out a false alarm than have a 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). 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. Paul 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 :-). -- Paul Secinaro | Synthetic Vision and Pattern Analysis Laboratory pss1@kepler.unh.edu | Department of Computer and Electrical Engineering p_secinaro@unhh.unh.edu | University of New Hampshire (603) 862-3287