3 ms·

No mention of on die ECC so far so I'll mention it. It's used in modern RAM (DDR5, maybe some DDR4) to improve yields. A borderline chip may pass tests if occas

No mention of on die ECC so far so I'll mention it. It's used in modern RAM (DDR5, maybe some DDR4) to improve yields. A borderline chip may pass tests if occasional bit errors are corrected before being read out. This is transparent to the OS as there is no mechanism that I'm aware of to report fixed bits or unfixable errors. I'm hopeful that this is going to help fix problems with occasional bit flips from cosmic rays and similar. Since it is used to keep marginal chips in the product stream, I'm not sure if it is really beneficial. The Raspberry Pi 4B claims DDR4 ECC RAM and I'm pretty sure that's on die ECC. I'd really prefer full blown ECC RAM and would pay a reasonable increase for it. I recently upgraded my desktop and sticking with ECC RAM would have cost hundreds of dollars more so I skipped it.

eptcyka 3y ago
ECC without error reporting still won't save one from data corruption. Ultimately, I want correctness not continuous but faulty operation. On-die ECC helps with the latter.
- mrob 3y ago
  Agreed. Reliability is the most important part of "reliability, availability and serviceability"[0]. Error correction is nice to have, but even simple parity checking is much better than nothing. I'd rather halt with a kernel panic than continue using corrupted data. [0] https://en.wikipedia.org/wiki/Reliability,_availability_and_serviceability https://en.wikipedia.org/wiki/Reliability,_availability_and_...
  - thfuran 3y ago
    And yet many developers insist it's better for the users to just swallow exceptions and carry on rather than halting on bad state.
    - brookst 3y ago
      It really depends on the application. Halting rather than displaying a slightly corrupted graphics texture is probably not what gamers want. Swallowing an exception in a finite element analysis is probably not what engineers want.
      - thfuran 3y ago
        It does depend on the application. And there's a whole lot of software for which the developers don't have complete enough understanding of everything downstream to really know the significance of incorrect output.

eptcyka 3y ago

ECC without error reporting still won't save one from data corruption. Ultimately, I want correctness not continuous but faulty operation. On-die ECC helps with the latter.

mrob 3y ago
Agreed. Reliability is the most important part of "reliability, availability and serviceability"[0]. Error correction is nice to have, but even simple parity checking is much better than nothing. I'd rather halt with a kernel panic than continue using corrupted data. [0] https://en.wikipedia.org/wiki/Reliability,_availability_and_serviceability https://en.wikipedia.org/wiki/Reliability,_availability_and_...
- thfuran 3y ago
  And yet many developers insist it's better for the users to just swallow exceptions and carry on rather than halting on bad state.
  - brookst 3y ago
    It really depends on the application. Halting rather than displaying a slightly corrupted graphics texture is probably not what gamers want. Swallowing an exception in a finite element analysis is probably not what engineers want.
    - thfuran 3y ago
      It does depend on the application. And there's a whole lot of software for which the developers don't have complete enough understanding of everything downstream to really know the significance of incorrect output.