Re: DRAM accommodations

On Sat, 7 Sep 2024 04:04:37 -0700, Don Y <blockedofcourse@foo.invalid>
wrote:

On 9/7/2024 2:56 AM, albert@spenarnc.xs4all.nl wrote:

Back of the napkin figures suggest many errors are (silently!) encountered
in an 8-hour shift.  For XIP implementations, it's mainly data that is at
risk (though that can also include control flow information from, e.g.,
the pushdown stack).  For implementations that load their application
into DRAM, then the code is suspect as well as the data!
>
[Which is likely to cause more detectable/undetectable problems?]

 
Running many day long computations for e.g. the euler project,
involving giga byte memories, and require precise (not one off
results),
I have not encountered any wrong results caused by RAM failures.

>
Do you KNOW that there haven't been any that your ECC *hasn't* silently
corrected for you?

ECC is there so they can increase dram density. Increasing density and
using multi levels per bit cell makes dram and flash cheaper and
increases the raw error rate, and adding ecc bits makes it tolerably
reliable, and that tradeoff is cost optimized.

It seems to work pretty well.

My PC here has 32Gbytes of dram and a terabyte of SSD, and seem fine.
The combination runs Spice fast and the results work.