SQLite Forum

How much would you trust a page-level checksum ?
Login
A single bit error is **certain** to change the checksum, no matter its length.

It is double bit errors that bring the checksum length into play. Because of the way checksums are calculated, over a word width usually, a second bit error, if it is in the same bit position within the sum word and has the opposite polarity flip, will cure the first bit error's effect upon the checksum.

One might think that cosmic rays (or alpha particle hits) would flip a dynamic memory storage cell the same direction all the time. But cell readout methods do not consistently treat a charged or discharged cell as a 1 or 0 respectively. So opposite polarity errors are as likely as same polarity errors.

So, what are the odds of an undetected error? To first order, they are:<code>
   (probability of one bit error over the block checked)
   * 
   (probability of another bit error over the block checked)
   /
   Nsum_bits / 2.
</code>. (That last 2 is because only half of the double bit errors "fix" the checksum.)

Of course, those bit error probabilities depend on how long the block is allowed to linger in a set of teensy capacitors.

Bit errors in persistent storage media are a different problem. There, for modern devices (recent decades), error detection and correction methods are used, which do not have the above weakness. As I recall, the errors undetected by the many-bit ECC methods are virtually always multi-bit errors for which a checksum is as fine as 1 / 2^Nsum_bits detection probability.