Error-correcting code, as in a type of memory that can correct single-bit errors. ECC memory is typically found on servers and workstations, where maximum reliability is required.

Information in modern computers is often stored in fixed quantities. E.g. eight bits may be stores as one byte.

Memory is reasonably stable and it is possible to just store the information as it is. However in rare cases the information becomes corrupted. In order to detect this corruption you need to store additonal information.

This can be done by adding an extra bit, the so-called parity bit. This allows you to detect single bit errors. It does not detect double bit errors nor can you reconstruct the informtion lost.

This is not always good enough. In those cases ECC is used. ECC uses an inteligent method to store 8 bits of information in 10 bits (thus is needs more cells and is more expensive). This allows it to correct a single bit error or detect up to two bits errors.

A simplified explanation of how this worked taken from this post here on SU

Imagine a 0 or an 1. If I read either then I just have to hope I read the right thing. If a 0 got flipped to a 1 by some cosmic radiation or by a bad chip then I will never know.

In the past we tried to solve that with parity. Parity was adding a ninth bit per 8 bits stored. We checked how many zeros and how many 1 were in the byte. The ninth was set to make that a even number. (for even parity) If you ever read a byte and the number was wrong, then you knew something was wrong. You do not know which bit was wrong though.

ECC expanded on that. It uses 10 bits and a complex algorithm to discover when a single bit has flipped. It also knows what the original value was. A very simple way to explain how it does that would be this:

Replace all 0s with 000. Replace all 1s with 111.

Now you can read six combinations:


We are never 100% sure what was originally stored. If we read 000 then that might have been just the 000 which we were expecting, or all three bits might have flipped. The latter is very unlikely. Bits do not randomly flip, though it does happen. Let say that happens one in ten times for some easy calculations (reality is much less). That works out to the following chances of reading the correct value:

000 -> Either 000 (99.9% sure), or a triple flip (1/1000 chance)

001 -> We know something has gone wrong. But it either was 000 and one bit flipped (1:10 chance), or it was 111 and two bits have flipped (a 1:100 chance). So let's treat it as if we read 000 but log the error.

010 -> Same as above.

100 -> Same as above.

011 -> Same as above, but assuming it was a 111

101 -> Same as above, but assuming it was a 111

110 -> Same as above, but assuming it was a 111

111 -> Either 111 (99.9% sure), or a triple flip (1/1000 chance)
111 -> Either 000 (99.9% sure), or a triple flip (1/1000 chance)

ECCs does similar tricks but does it more efficiently. For 8 bits (one byte) they only use 10 bits to detect and correct.

history | excerpt history