🚀 go-pugleaf

In <dillon.3992@overload.UUCP>, dillon@overload.UUCP (Matthew Dillon) writes:
>>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.

In the context of the posting I replied to, that of a life supporting or Very
Important Application implementation, parity is indeed useless, and ECC can be
seen as coming as close to mandatory as anything can be.  An exception to this
might be if it is implemented as multiple 'majority rules', identical
computers.

The fact that a properly designed ECC scheme can correct errors in the ECC bits
themselves makes it far more desirable for reliability and recoverability,
though at a greater cost.

Parity schemes, on the other hand, cannot detect the failure of a parity bit
itself, and thus reduces the overall reliability as a tradeoff for knowing when
you had an error, even if that error is meaningless and would not have happened
without the parity bit being present.  Statistically speaking, if parity is
checked on a byte basis, 1/9 of all single bit errors could be safely ignored,
and that takes into account ONLY the parity rams themselves, without taking
into account the current contents of the memory itself, the importance of the
application taking the hit, etc.

>    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.

Assuming that an MMU is in place, and assuming that the error was a random
event caused by external forces (cosmic rays, whatever), the page may or may
not require mapping out, though with parity checking only, you really don't
have a lot of choice. With an ECC scheme, the system can make note of the error
and keep using the memory, allowing it to map the page out when the number of
errors exceeds a threshhold over a predefined period of time. It will also
allow reporting of single bit errors to the operator, who can make a good
judgement as to the root cause, and take action as appropriate.

Parity is a heavy-handed beast, telling you little, and treating all memory as
equal. Should video memory be parity checked, assuming that you can readily
identify where the video is being displayed from? If so, should you crash and
burn because a picture has a pixel showing a bad colour? If not, can you trust
the figures your spreadsheet shows? If you don't crash and burn, should you
ignore the red light? Should you panic? Either way, you could be wrong.

Hardware is getting cheaper all the time. ECC is a little more expensive than
parity. In some ways, it can be said to be cheaper, if you count the lost
productivity when an error occurs  that cannot be corrected, and would not
matter to the application.

In Very Important Applications, I would go for ECC.  In other situations, I
would go for no checking at all. Parity is useless.

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

You rest my case. :-)

-larry

--
The raytracer of justice recurses slowly, but it renders exceedingly fine.
+-----------------------------------------------------------------------+ 
|   //   Larry Phillips                                                 |
| \X/    lphillips@lpami.wimsey.bc.ca -or- uunet!van-bc!lpami!lphillips |
|        COMPUSERVE: 76703,4322  -or-  76703.4322@compuserve.com        |
+-----------------------------------------------------------------------+