What is the difference between parity and non parity when concerning EDO RAM for a pentium 166HZ? I would like to get more memory for my old PC. I need EDO 72pin SIMMS. But when asked the question as to parity and non parity, I did not know. Please educate me, I would be ever so greatful.
Tek-Tips is the largest IT community on the Internet today!
Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!
-
Congratulations Mike Lewis on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!
EDO Memory 1
- Thread starter Cmbrando
- Start date
-
1
- #2
Parity vs. Non-Parity: Pros and Cons
For many people, like me, the decision to use parity memory is clear-cut; for many others the decision to not bother with it is. Others are willing to consider the arguments and make a decision--this section is for you. While I make no secret that I think it is an unwise risk to not use parity memory, there are situations where it makes sense, and valid technical arguments against using it. There are also a lot of bogus misconceptions about it that cause people to make poor decisions in this regard. It is these that I wish to dispel here.
First, the easy cases. If your system requires the use of parity memory and parity checking cannot be disabled, you must use parity memory, unless you want to use the heinous false parity memory. This is not recommended, although if you know what it is, using it is no worse than running a parity system with checking turned off. If your system doesn't support parity checking, you can't do parity checking, obviously. The rest of this section assumes that you have a choice of which to use.
I would state the following as the advantages of using parity checking/ECC:
Data Integrity: You run far less risk of a memory problem causing corruption and possible data loss. With ECC errors can be corrected on the fly. Even with regular parity checking you avoid writing bad data to your disk and accumulating errors that can cause long-term data loss. See here for details on the types and causes of memory errors.
Easier Troubleshooting: If you don't use parity checking, any time you have a strange glitch in your system you cannot rule out a memory problem being the cause. When you run with parity checking in place you know most of the time when a problem is related to memory.
Advance Warning of Hardware Failure: Many hardware failures over time can manifest themselves through parity errors in a parity checking system. Without parity, these can remain hidden and hard to diagnose.
These I consider disadvantages of parity checking or ECC:
Greater Expense: Parity memory costs more than non-parity in most cases.
Harder to Find: Parity memory can be more difficult to buy, especially in the newer technologies.
Occasional False Positives: Any time a parity error occurs, there is a 1 in 9 chance that the bit that was inverted to cause the error was actually the parity bit itself. This means that the 8 data bits themselves were fine, and if parity had not been in use there would have been no problem at all. This really does not apply to ECC, which would handle this situation with no difficulty.
Poor Error Handling: Regular parity checking deals with a parity error by sending a non-maskable interrupt (NMI) to the processor, halting the system immediately. Depending on the timing of this, it can cause lost data. (But not the accumulation of data errors over time as with non-parity). This does not apply to ECC (except in the very rare case of a double-bit error).
Performance Penalty For ECC: ECC does cause a minor slowdown in system performance.
Here are some of the arguments I have heard against using parity checking or ECC (other than the disadvantages listed above) and what I have to say about them:
"Parity checking is overkill, I don't need it, and it's too expensive": This may be true for some people. You have to decide for yourself if using parity memory is important enough to justify the additional cost. It all comes down to how important your data is to you; a lot of people don't care very much about their data it seems (just look at how many never back up their hard disks).
"You are more likely to encounter a software bug than a memory error, so why bother?": This is a rather silly argument; the whole point of parity memory is that you get some idea if you are really having software problems or not--wouldn't you want to know? How are you going to figure out if you have a hardware problem or just a buggy or corrupted program? Just because there are other problems that can occur with a PC system doesn't mean that protecting yourself against ones that you can protect against makes no sense.
"If parity checking is so important, why don't other parts of the PC use it?": Guess what: they do. In fact, on a PC with no parity memory, the memory is one of the few components that is running without protection from data corruption. Hard disks, CD-ROM drives, even floppy drives all use error detecting and correcting circuitry. Newer Pentium II processors have added it for the secondary cache bus; if error detection is such overkill, why is Intel adding it to the cache bus, something that hasn't had error detection on it before, I must wonder? Modem and network communications devices are similarly protected. Even the system BIOS has a checksum that provides memory error detection for its settings.
"Modern RAM rarely has errors, parity was only needed for older systems": Partially true; I'd say it's more that parity was more needed for older systems. Newer memory is more reliable but also newer systems are more likely to run at the margin of reliable performance, due to increased speed, heat inside the box, and the overall lower quality of components used in many cheaper machines today.
"Parity errors cause the system to halt so they cause just as much data loss as unchecked memory errors, because you lose whatever you were working on when the system is halted": This is in my opinion the most valid reason for not using parity checking, but there is still one difference: at least you know you have a problem. You won't continue using a corrupted version of that big report your boss is waiting for. Also, this argument does not apply to ECC, which will correct the vast majority of errors seamlessly.
"Parity checking slows down the PC": This is a myth. Parity-checked memory is no slower than regular non-parity memory, although ECC is a bit slower. Read this section.
"Parity checking is unreliable because the parity checking circuit could fail": This is a bogus argument, for two reasons. First, the parity checking circuit is built into other components that are far more complicated than it is; parity checking is extremely simple logic that has been basically unchanged for 20 years. The chances of it failing in isolation from the rest of the motherboard are infinitesimally small. Second, arguing that using no protection is better than using protection that will almost always work, makes no sense. In a way, this is like arguing that having an emergency brake in your car is a bad idea because some day there is a remote chance that you might pull it and have it not work. Is it better to have a 99.999% chance of it working or a 0% chance of it working?
"Parity checking isn't worthwhile because it doesn't even detect double-bit errors": Somewhat surprisingly, I hear this one a lot. Surprisingly because it's so silly. First, single-bit errors are by far the most common problem. Second, virtually every Pentium-class or later PC today that supports parity checking also supports ECC, which will detect double-bit errors. Finally, again, it does not make sense to discard protection against something relatively common (single-bit errors) just because it doesn't protect against something relatively rare (double-bit errors).
So where does this leave you? Well, you must decide what is important to you. If you are running a 50-user server, or working on a million-dollar project plan, saving a few bucks using non-parity memory is insane. If you are trying to put together a bargain machine for running games and doing light word processing, the situation is rather different. Still, I read all the time about people setting up file servers on overclocked PCs with non-parity memory. Where exactly are the savings if someone's work is corrupted?
You must decide based on the information presented, whether going with non-parity memory makes sense for your situation. Just remember that having memory protection is kind of like having a fire detector. Most people will never need theirs, but the few that do will be very glad they had them when the time arises. I personally have had parity memory save me a lot of headaches on more than one occasion.
Found on.....give the credit to them.
For many people, like me, the decision to use parity memory is clear-cut; for many others the decision to not bother with it is. Others are willing to consider the arguments and make a decision--this section is for you. While I make no secret that I think it is an unwise risk to not use parity memory, there are situations where it makes sense, and valid technical arguments against using it. There are also a lot of bogus misconceptions about it that cause people to make poor decisions in this regard. It is these that I wish to dispel here.
First, the easy cases. If your system requires the use of parity memory and parity checking cannot be disabled, you must use parity memory, unless you want to use the heinous false parity memory. This is not recommended, although if you know what it is, using it is no worse than running a parity system with checking turned off. If your system doesn't support parity checking, you can't do parity checking, obviously. The rest of this section assumes that you have a choice of which to use.
I would state the following as the advantages of using parity checking/ECC:
Data Integrity: You run far less risk of a memory problem causing corruption and possible data loss. With ECC errors can be corrected on the fly. Even with regular parity checking you avoid writing bad data to your disk and accumulating errors that can cause long-term data loss. See here for details on the types and causes of memory errors.
Easier Troubleshooting: If you don't use parity checking, any time you have a strange glitch in your system you cannot rule out a memory problem being the cause. When you run with parity checking in place you know most of the time when a problem is related to memory.
Advance Warning of Hardware Failure: Many hardware failures over time can manifest themselves through parity errors in a parity checking system. Without parity, these can remain hidden and hard to diagnose.
These I consider disadvantages of parity checking or ECC:
Greater Expense: Parity memory costs more than non-parity in most cases.
Harder to Find: Parity memory can be more difficult to buy, especially in the newer technologies.
Occasional False Positives: Any time a parity error occurs, there is a 1 in 9 chance that the bit that was inverted to cause the error was actually the parity bit itself. This means that the 8 data bits themselves were fine, and if parity had not been in use there would have been no problem at all. This really does not apply to ECC, which would handle this situation with no difficulty.
Poor Error Handling: Regular parity checking deals with a parity error by sending a non-maskable interrupt (NMI) to the processor, halting the system immediately. Depending on the timing of this, it can cause lost data. (But not the accumulation of data errors over time as with non-parity). This does not apply to ECC (except in the very rare case of a double-bit error).
Performance Penalty For ECC: ECC does cause a minor slowdown in system performance.
Here are some of the arguments I have heard against using parity checking or ECC (other than the disadvantages listed above) and what I have to say about them:
"Parity checking is overkill, I don't need it, and it's too expensive": This may be true for some people. You have to decide for yourself if using parity memory is important enough to justify the additional cost. It all comes down to how important your data is to you; a lot of people don't care very much about their data it seems (just look at how many never back up their hard disks).
"You are more likely to encounter a software bug than a memory error, so why bother?": This is a rather silly argument; the whole point of parity memory is that you get some idea if you are really having software problems or not--wouldn't you want to know? How are you going to figure out if you have a hardware problem or just a buggy or corrupted program? Just because there are other problems that can occur with a PC system doesn't mean that protecting yourself against ones that you can protect against makes no sense.
"If parity checking is so important, why don't other parts of the PC use it?": Guess what: they do. In fact, on a PC with no parity memory, the memory is one of the few components that is running without protection from data corruption. Hard disks, CD-ROM drives, even floppy drives all use error detecting and correcting circuitry. Newer Pentium II processors have added it for the secondary cache bus; if error detection is such overkill, why is Intel adding it to the cache bus, something that hasn't had error detection on it before, I must wonder? Modem and network communications devices are similarly protected. Even the system BIOS has a checksum that provides memory error detection for its settings.
"Modern RAM rarely has errors, parity was only needed for older systems": Partially true; I'd say it's more that parity was more needed for older systems. Newer memory is more reliable but also newer systems are more likely to run at the margin of reliable performance, due to increased speed, heat inside the box, and the overall lower quality of components used in many cheaper machines today.
"Parity errors cause the system to halt so they cause just as much data loss as unchecked memory errors, because you lose whatever you were working on when the system is halted": This is in my opinion the most valid reason for not using parity checking, but there is still one difference: at least you know you have a problem. You won't continue using a corrupted version of that big report your boss is waiting for. Also, this argument does not apply to ECC, which will correct the vast majority of errors seamlessly.
"Parity checking slows down the PC": This is a myth. Parity-checked memory is no slower than regular non-parity memory, although ECC is a bit slower. Read this section.
"Parity checking is unreliable because the parity checking circuit could fail": This is a bogus argument, for two reasons. First, the parity checking circuit is built into other components that are far more complicated than it is; parity checking is extremely simple logic that has been basically unchanged for 20 years. The chances of it failing in isolation from the rest of the motherboard are infinitesimally small. Second, arguing that using no protection is better than using protection that will almost always work, makes no sense. In a way, this is like arguing that having an emergency brake in your car is a bad idea because some day there is a remote chance that you might pull it and have it not work. Is it better to have a 99.999% chance of it working or a 0% chance of it working?
"Parity checking isn't worthwhile because it doesn't even detect double-bit errors": Somewhat surprisingly, I hear this one a lot. Surprisingly because it's so silly. First, single-bit errors are by far the most common problem. Second, virtually every Pentium-class or later PC today that supports parity checking also supports ECC, which will detect double-bit errors. Finally, again, it does not make sense to discard protection against something relatively common (single-bit errors) just because it doesn't protect against something relatively rare (double-bit errors).
So where does this leave you? Well, you must decide what is important to you. If you are running a 50-user server, or working on a million-dollar project plan, saving a few bucks using non-parity memory is insane. If you are trying to put together a bargain machine for running games and doing light word processing, the situation is rather different. Still, I read all the time about people setting up file servers on overclocked PCs with non-parity memory. Where exactly are the savings if someone's work is corrupted?
You must decide based on the information presented, whether going with non-parity memory makes sense for your situation. Just remember that having memory protection is kind of like having a fire detector. Most people will never need theirs, but the few that do will be very glad they had them when the time arises. I personally have had parity memory save me a lot of headaches on more than one occasion.
Found on.....give the credit to them.
- Status
Similar threads
- Locked
- Question
- Locked
- Question
- Locked
- Question