# Effectiveness of Parity Checking

A parity bit lets a receiver know whether or not the an input is correct, given the number of 1's matches the logic behind the parity bit (be it even = 1, or odd =1). This seems very ineffective to me, and even 'corrupting' (not sure what the right word would be).

What if the message is not corrupted, but the parity is corrupted, does this means the message has to be resent? Or does the parity check have a way around this? And what if 2 bits flip, so the number of 1's doesn't change, so there is no parity error, but now the message has changed.

Am I understanding parity checking incorrectly, am I missing something more with the parity, or is it really that ineffective of an error checker? The reason this is throwing me off is because if it really is this ineffective, why is it taught so much (at least in my program at my university), and these issues are practically ignored.

• The parity bit is added to the data to ensure an even (or odd) number of 1's. Yes it's a very primitive error correction method and yes if two bits flip you're not going to get a parity error. Maybe you are being taught this method simply to get you thinking more deeply about error correction and its benefits and limitations. – Ryan Griggs Feb 9 '17 at 3:23
• @RyanGriggs it is a weak error detection scheme, but not an error correction one. – Chris Stratton Feb 9 '17 at 4:23
• Sorry I used the wrong word. Should have said Detection. Thanks Chris! – Ryan Griggs Feb 9 '17 at 4:24
• A parity check will not tell you if message is correct, but it will tell you if a message is wrong. A parity fail is always a wrong message, a parity pass might be a good message, a good message always passes parity, a bad message may fail parity. – Neil_UK Feb 9 '17 at 6:33

You seem to understand parity generation/checking but it is only one technique out of many that are used. It is not in general used as the means of checking data within a message composed of many bytes.

Parity was one of the earliest data checking techniques and has been traditionally used where the data is very limited such as 8 bits over a hardware link - such as a parity bit on a memory bus. The behavior when an error is detected depends upon the system. The advantage of parity is its simplicity and low overhead.

In a communication system where the data is combined into messages the most common approach is to use a Cyclic Redundancy Check (CRC) or checksum where a 16-32 bit word is appended to the message. This can detect more than single bit errors.

More advanced techniques such as Reed-Solomon codes can not only detect but also correct errors.

In terms of effectiveness even parity can give good value for systems that have a low error rate - if the chance of a single bit error is 1 in 10^9 and errors are independent the chance of getting an undetected error due to a 2-bit error would be 1 in 10^18 which is minuscule and never likely to occur in the life of the system.

When using parity the system designer must ensure that simple correlated errors do not cause failure - for example if using ODD parity on a system where a cable being disconnected would cause all bits in a byte to be a 1 would mean that the disconnected cable would not be detected - that particular fault could be detected if EVEN parity was used.

However simple parity would not be good choice though on a wireless system where the raw error rate might be 1 in 10^3 where the chances of a double bit error could occur in a very short time. For a wireless link much more sophisticated error detection and correction would be used.

The simple parity checking is really such simple as you state. But uneffective is probably not the right word for just one bit - it cannot take more information, than just 2 states 0/1. If your channel is basically reliable, then it can catch occasional glitch good for really low prize and simple computing.

If you have less reliable line (such as 2 or more errors are common in one transfer), than you have to sacrifice more bits for parity check and it is then able to catch a lot more errors. (and it is used widely in reality).

You can also protect larger blocks (like not every byte separatly with 1 bit parity, but say 8 bytes with 1 byte=8bits of parity and be able to chatch a lot more errors this way).

But in school it is critical to understand the concept of checking validity of data and the 1 bit parity is so easy, that it demonstrate it clearly without any higher mathematic or formulas, so everybody grasp the basic idea - protect data is needed, but comes at cost.

Later you can learn more effective (but complicated too) ways to protect data, but the esencial clarity is obscured somehow with more complicated schemas. (You do not want to start with RAID 11 combined with encrypted signing each file - nice, but hard to understand all concepts used at one time).

At basic school you too start with adding two 1 digit long numbers and have to be really good at it, before continue to multipling/dividing arbitrary long numbers.

• How would you use more bits to check parity? – Mahmud Ahmad Feb 9 '17 at 16:08
• en.wikipedia.org/wiki/Category:Error_detection_and_correction lists a lot of diferent schemas, how improve detecting errors and/or correcting them, if you can spare more bits. Depend how much you can spend over and for what purpouse. – gilhad Feb 10 '17 at 9:14
• @MahmudAssamaray If you XOR the bytes of a message together, the resulting final byte is essentially 8 even parity bits in parallel, referred to as a "parity byte" or "LRC". – bryc Apr 12 '19 at 23:40