paryavi@harris.cis.ksu.edu (Saiid Paryavi) (09/21/89)
Does anyone know what the difference between parity and non-parity RAM is in
the Mac IIci? Does it have to do with the speed of the RAM? Does one type
run faster than the other or is it that one is more reliable???
--
Saiid Paryavi Computer Science Dept.
Internet: paryavi@harris.cis.ksu.edu Nichols Hall
BITNET: paryavi@ksuvax1.bitnet Kansas State University
UUCP: {rutgers, texbell}!ksuvax1!harry!paryavi Manhattan, KS 66506c8s-an@franny.Berkeley.EDU (Alex Lau) (09/22/89)
In article <0xe23@deimos.cis.ksu.edu> paryavi@harris.cis.ksu.edu (Saiid Paryavi) writes: >Does anyone know what the difference between parity and non-parity RAM is in >the Mac IIci? Does it have to do with the speed of the RAM? Does one type >run faster than the other or is it that one is more reliable??? As I understand it, parity-checking RAM runs an error check while non-parity-checking RAM doesn't. Parity-checking RAM is a mite slower and slightly more expensive, although the MS-DOS market is full of parity-checking RAM machines so the demand is higher and sometimes the prices are actually lower for the RAM itself. Also as I understand it, Apple included an option for parity-checking RAM in the IIci because many major corporations and certain divisions of the government require it. Apple had a tech note (I forget which number) explaining why they didn't use parity-checking; I guess that will soon be updated... >Saiid Paryavi Computer Science Dept. --- Alex UUCP: {att,backbones}!ucbvax!franny!c8s-an INTERNET: c8s-an%franny.berkeley.edu@ucbvax.berkeley.edu FIDONET: Alex.Lau@bmug.fidonet.org (1:161/444)
chuq@Apple.COM (Chuq Von Rospach) (09/22/89)
>Does anyone know what the difference between parity and non-parity RAM is in >the Mac IIci? Does it have to do with the speed of the RAM? Does one type >run faster than the other or is it that one is more reliable??? Parity RAM is 9 bit ram SIMMS (and support hardware) instead of 8 bit ram SIMMS. Parity RAM is more expensive, not any faster and somewhat more reliable, although RAM reliability is high enough these days that unless you're writing RFC's for government contracts or totally paranoid, not terribly useful. All parity does is check to make sure that the eight bits you wrote into the RAM come out again the same way (but only if you flip one bit. Parity doesn't cover multi-bit errors. You need ECC to do that). There's no reason why a 'normal' user needs parity unless their applications require extremely high reliability. -- Chuq Von Rospach <+> Editor,OtherRealms <+> Member SFWA/ASFA chuq@apple.com <+> CI$: 73317,635 <+> [This is myself speaking. I am not Appl Segmentation Fault. Core dumped.
roy@phri.UUCP (Roy Smith) (09/22/89)
In <0xe23@deimos.cis.ksu.edu> paryavi@harris.cis.ksu.edu (Saiid Paryavi): > Does anyone know what the difference between parity and non-parity RAM is in > the Mac IIci? Does it have to do with the speed of the RAM? Does one type > run faster than the other or is it that one is more reliable??? Parity is a scheme used for detecting memory errors. It can take many forms, but the basic idea is that for each 8-bit byte, you actually store 9 bits in the memory. Everytime you write a byte (or word, or whatever the appropriate memory transfer unit is) to memory, the hardware counts the number of ones in the 8 data bits and makes the 9th bit (the parity bit) either a one or a zero such that the total number of ones in the 9 bits is even (or, depending on the machine, odd; it doesn't really matter as long as it's consistant). Whenever a byte is read from memory, the hardware again counts the number of ones in the 8 data bits, calculates what the parity bit should have been, and checks to make sure it really is that. If it's not, that means a bit was either turned from a one to a zero or from a zero to a one, either case meaning a memory error. The hardware then signals a parity error and presumably the operating system does something about it, often simply just printing an error message and halting. To get back to your questions, it has nothing to do with the speed of the ram chips. The disadvantages of parity memory are that it takes more chips (9/8ths as many in the common case described above) and the memory system as a whole will probably be slower, even if the ram chips themselves are the same speed, because of the added parity generation and checking required. This speed delay is generally pretty marginal. If you've ever looked at a typical Mac SIMM, you will notice that there are 8 chips and a space on the board for a ninth. That's for the chip which will hold the parity bits. With simple parity, there is no way to know which bit has the error in it, nor is there any way to correct the error on-the-fly. There are more complicated parity-like schemes, called Error Correcting Codes (ECC) which not only let you detect errors, but lets you track down exactly which bit within the word was bad, and lets the memory system correct it before the CPU gets the data. These take even more memory chips (typically something like an extra 7 bits for every 32), and incur an even greater memory speed delay. Larger systems usually have ECC memory. -- Roy Smith, Public Health Research Institute 455 First Avenue, New York, NY 10016 {att,philabs,cmcl2,rutgers,hombre}!phri!roy -or- roy@alanine.phri.nyu.edu "The connector is the network"
roy@phri.UUCP (Roy Smith) (09/22/89)
In article <34935@apple.Apple.COM> chuq@Apple.COM (Chuq Von Rospach) writes: > RAM reliability is high enough these days that unless you're writing RFC's > for government contracts or totally paranoid, not terribly useful. [...] > There's no reason why a 'normal' user needs parity unless their applications > require extremely high reliability. This is a matter of opinion, and clearly Chuq is entitled to his, but I disagree. We've gone through about 200 Mbyte-years of Sun-3/50 (parity) memory here. I've seen 3 memory failures which the parity systems caught. That's one failure every 65 or so Mbyte-years. The usual mode of failure is an isolated parity error, then another one a few months or weeks later, then occuring with increasing frequency until eventually it becomes a hard error at which time it becmes easy to track down using memory diagnostics. Lets assume that Mac memory is about as reliable as Sun memory (although this may be apples and oranges, we're also comparing 1989 technology to 1986 technology). We've got about 30 Mbytes of installed Mac memory (not quite true; 8 of those are sitting on a shelf in front of me, but should be installed this afternoon, but then again, I'm also currently writing budget requests for Macs with another 10-20 Mbytes worth of ram) here, so we should expect to see on the order of one memory failure every other year. Without parity to detect it, all we'll see is random unexplained crashes (or worse, silent data corruption). So, I conclude that while Chuq's opinion is not totally off the wall, he is erring on the side of risk, while I'm taking a more conservative point of view. A typical user with a 1 Meg MacPlus at home might very well not see a parity error for decades (i.e. never). On the other hand, for any place with an installed base of more than a couple of Macs, the odds that they will see a parity error in the course of a few years is reasonably high. And a large shop, with dozens or even hundreds of Macs with lots of memory in each, might be seeing many memory errors a year. And, even if ram technology has gotten better, there are other reasons why memory errors might occur (for example, I suspect the snap-in SIMMs in Mac-IIs are more likely to suffer mechanical connection problems than the soldered-in chips in our Sun-3/50s). -- Roy Smith, Public Health Research Institute 455 First Avenue, New York, NY 10016 {att,philabs,cmcl2,rutgers,hombre}!phri!roy -or- roy@alanine.phri.nyu.edu "The connector is the network"
chuq@Apple.COM (Chuq Von Rospach) (09/22/89)
>Gee ... I thought apples (Macs) didn't have parity circuitry built in >to them. Parity mem in a Mac is just wasted!? The new Mac IIci supports parity as an option. It is currently the only Mac that has parity support. -- Chuq Von Rospach <+> Editor,OtherRealms <+> Member SFWA/ASFA chuq@apple.com <+> CI$: 73317,635 <+> [This is myself speaking. I am not Appl Segmentation Fault. Core dumped.
jpainter@tjp.East.Sun.COM (John Painter - Sun BOS Hardware) (09/23/89)
In article <34935@apple.Apple.COM> chuq@Apple.COM (Chuq Von Rospach) writes: >There's no reason why a 'normal' user needs parity unless their applications >require extremely high reliability. Gee ... I thought apples (Macs) didn't have parity circuitry built in to them. Parity mem in a Mac is just wasted!? BTW I have some parity simms (happened on a good deal) and some non-parity (happened on an even better deal) simms in my SE with no bad effects. (Also one simm has mixed 100ns and 80ns parts. Hardware doesn't care, It just wants 'em faster than 150ns (120ns for MacIIs and up??) /Tjp -disclaimer I just right software and build computers. Why would I know?
pepke@loligo (Eric Pepke) (09/23/89)
In article <34935@apple.Apple.COM> chuq@Apple.COM (Chuq Von Rospach) writes: >Parity RAM is 9 bit ram SIMMS (and support hardware) instead of 8 bit ram >SIMMS. Parity RAM is more expensive, not any faster and somewhat more >reliable, although RAM reliability is high enough these days that unless >you're writing RFC's for government contracts or totally paranoid, not >terribly useful. > >All parity does is check to make sure that the eight bits you wrote into the >RAM come out again the same way (but only if you flip one bit. Parity >doesn't cover multi-bit errors. You need ECC to do that). Parity memory is less, not more, reliable than non-parity memory. All that parity does is, under certain conditions, alert the processor that a single bit error has occured. The effect of parity on most systems is to halt the processor or kill the process rather than allow the program blithely to process the value on the assumption that it is correct. Because parity requires an extra bit per byte, it actually increases the probability that bit errors will occur. Assuming all the obvious things, parity memory will be about 9/8 as likely to fail within a period of time as non-parity memory. About 1/9 of these failures will be failures of the parity bit which can be avoided by leaving the parity bit out of the system. As far as multi-bit errors go, there is a well-known kind of ECC called SECDED (Single Error Correction Double Error Detection), and it's obvious what that does. There are a lot of ways to detect multi-bit errors without using ECC, including the ever-popular CRC. >There's no reason why a 'normal' user needs parity unless their applications >require extremely high reliability. Even a user who requires high reliability would not get it from parity. Parity would only benefit people who would rather see the system hang than produce a wrong answer or execute a wild instruction. Parity only changes the kind of unreliability. Which kind is the more desirable is debatable and may be a matter of taste. Eric Pepke INTERNET: pepke@gw.scri.fsu.edu Supercomputer Computations Research Institute MFENET: pepke@fsu Florida State University SPAN: scri::pepke Tallahassee, FL 32306-4052 BITNET: pepke@fsu Disclaimer: My employers seldom even LISTEN to my opinions. Meta-disclaimer: Any society that needs disclaimers has too many lawyers.
nagle@well.UUCP (John Nagle) (09/25/89)
In article <4004@phri.UUCP> roy@phri.UUCP (Roy Smith) writes: >In <0xe23@deimos.cis.ksu.edu> paryavi@harris.cis.ksu.edu (Saiid Paryavi): >... and the >memory system as a whole will probably be slower, even if the ram chips >themselves are the same speed, because of the added parity generation and >checking required. In general, this isn't the case, and nothing in the Apple data sheets indicates that there's a speed penalty associated with installing parity memory in the Mac. In systems that don't correct errors, most designs don't hold up delivery of the data on a read until the parity check is made. With ECC, it's a different story, since the correction logic has to delay delivery of the data at least until the check is complete, and in the presence of errors, perhaps longer. The big unanswered question is what happens when a parity error is detected. Does the Mac OS properly support the detection hardware, and if so, what does it do with an error? Does A/UX support it? Is there error logging, as on Sun machines? It would be good to get field experience with the error logs, and find out what the real error rates are. John Nagle