🚀 go-pugleaf

>In article <3620@tymix.UUCP> pnelson@hobbes.uucp (Phil Nelson) writes:
>In article <1641@lpami.wimsey.bc.ca> lphillips@lpami.wimsey.bc.ca (Larry Phillips) writes:
>
>>Right.. ECC is not parity, and vice versa. Parity checking is totally,
>>completely, and utterly useless.
>
>Oh really? Please explain why parity checking would not have saved me much
>
> The advantage of parity checking is diagnostic, intermittent problems on


    I have a tendancy to agree.  ECC is cute but expensive.  It takes 7
    bits of ECC to detect and correct 1 bit in a 32 bit wide word.  The way
    you think about 1-bit-ECC is that you need enough codes to generate the
    address of the incorrect bit, plus a no-error code, plus a parity bit.
    Unfortunately, that no-error code takes us from 5 to 6 bits, then one
    more to parity-check the ECC code itself.  A 1-bit ECC can correct 1 bit
    errors and detect 2-bit errors.

    2+ bit correct is MUCH more difficult (think of the # of codes required...
    at least double the number of bits as for 1 bit ECC but the analogy I
    used above no longer holds, so it's even more!).  When you get into >1
    bit ECC you generally switch to burst-error correction (which requires
    fewer correct-codes and thus fewer bits of ECC).  Unfortunately, burst
    error correction is useless when the medium is memory.

    A simple 1-bit parity check is sufficient to detect the problem that
    ECC would have corrected, and allow the processor to map the page out
    with its MMU.  In anycase, this kind of failure occurs less often than
    you think.	What most people come up against is a BAD DRam (i.e. cause
    of problem is not alpha radiation), in which case it is not reliable
    anyway and you simply have to replace the chip.

    DRAMs these days are much more reliable than 10 years ago... even 5 years
    ago.

--


    Matthew Dillon	    uunet.uu.net!overload!dillon
    891 Regal Rd.
    Berkeley, Ca. 94708
    USA