9 ms·

More RAM is always nice but I'm secretly hoping we'll start to see more ECC support in the future. With these humongous modules and even with a teeny tiny bitfl

More RAM is always nice but I'm secretly hoping we'll start to see more ECC support in the future. With these humongous modules and even with a teeny tiny bitflip probability corruption chance becomes non insignificant.

bheadmaster 3y ago
Runtime asserts and invariant checks in software can also help a lot with isolating bitflip errors. With a nice addition of also isolating effects of software bugs.
- mastax 3y ago
  Assuming the compiler doesn't optimize them out.
- gumby 3y ago
  ECC is better handled in hardware: most of the time it won’t happen, and the hardware can more easily interrupt the processor so the kernel can correct the problem or signal a fault if it’s not a correctable corruption.
- GuB-42 3y ago
  I don't know if it is significant. Runtime checks tend to focus on small but critical part of the data, like size fields. It usually doesn't check bulk data, like decompressed image data, or code, and it also may not be effective if data is in cache. Furthermore, it will only detect errors, not correct them. Also the performance cost is, I think, much higher than the extra RAM chip. Good coding practice for critical path in software, but clearly, it doesn't substitute for dedicated hardware. I have had defective RAM, and I got quite a bit of corruption before the first crashes, it is hardly noticeable when it is just a pixel changing color in a picture, but it is still something you don't want. ECC would have prevented that. I know there is software resistant on random bitflips, like for satellites exposed to cosmic rays, but it is a highly specialized field. It is also a field where they use special chips, typically with coarser (and therefore less efficient) dies that are more resistant to radiation. You leave a lot on the table for that.
- ElectricalUnion 3y ago
  I thought that the current wave of compiler correctness checking, zero-cost abstractions, JIT compilers and speculative processor behaviour were all about removing those "unnecessary" runtime asserts and invariant checks to get better performance.
- lazide 3y ago
  Those only help isolate somewhat predictable errors. Which is rare for what ECC is designed to protect against. If it’s a random, once in several billion reads/writes issue, it can just stop/identify the bad data from further propagating. Sometimes. That data is still lost. ECC does forward error correction, which is extremely rare for the type of data protection you’re talking about. and if the data is corrupted in RAM (say when initially loaded/read) before the software can apply FEC, there is nothing the software can do.
Aurornis 3y ago
These are individual memory chips. They can be used to build both ECC modules and non-ECC modules. ECC modules just have more chips to store the extra parity information. In the high capacity RDIMM server market there are plenty of ECC options.
- deleted 3y ago
  [deleted]
- spystath 3y ago
  Oh yes, I understand that. I only wish that ECC support in general starts getting more traction in consumer electronics. Nowadays (unless you go to super noisy super expensive server hardware) maybe with an AMD processor maybe a motherboard manufacturer will have a 20-links-deep document that says that these ECC modules may be supported, proceed at your own risk, might set your flat on fire, kill kittens etc. When you had a couple of gigs of ram it was probably irrelevant but if you have multiple TB of RAM caching file access ECC should become normalised.
  - Aurornis 3y ago
    ECC isn’t that hard to get in consumer platforms now. The situation has changed a lot from what you’re thinking. You can get ECC support on Intel 12th and 13th generation parts by buying a motherboard with a W680 chipset. You can get ECC support on modern AMD CPUs by picking a motherboard that lists ECC support listed on the product page. It’s not that hard.
    - rini17 3y ago
      And you can get reasonably priced notebook with ECC by...?
      - Aurornis 3y ago
        Lenovo has them. Again, not hard if you look. I know some people won’t be happy until every laptop has ECC RAM and is super cheap, but the reality is that the demand for ECC RAM is very low. The majority of users would choose the extra battery life and lower price if given the option.
bpye 3y ago
I really wish we’d just get in-band ECC on normal consumer platforms. That way we’d need no special DIMMs, in applications where ECC was desired it could be enabled and the capacity penalty would be paid, in other applications it could be disabled and no capacity would be lost.
- gabereiser 3y ago
  I like this idea. 64gb of ram non-ecc, 48gb in ecc. Dynamic, succinct, and enables more supply chain cross over for not having two (three?) separate DIMM types.
- Aurornis 3y ago
  Having physical memory segments be different logical sizes at runtime depending on the ECC setting does not sound fun. Having your system’s available memory fluctuate up and down based on how many segments are currently set to ECC also doesn’t sound fun. Having developers manually turn ECC off for regions where it’s unimportant sounds like a lot of complexity for a relatively rare use case. There is in-band ECC in some newer Intel designs, but it’s all or nothing. Adding extremely complexity to memory management to selectively disable it sounds like a lot to ask.
  - gabereiser 3y ago
    I believe it would just be a kernel setting. Developers would just see full capacity or ecc-capacity, they wouldn’t care much why.
    - Aurornis 3y ago
      It’s implemented as a BIOS setting where it’s supported. But the parent comment was suggesting that it be on or off depending on the memory segment, which is a completely different problem.
      - saltcured 3y ago
        I don't see "segment" in the earlier post at all. I think your reading depends on thinking "application" means "process", while another reading would be that an application is a particular deployed system, where this setting can be altered e.g. at the BIOS level.
hinkley 3y ago
Doesn’t DDR5 require ECC to function properly? I think we’ve gotten to the point that we need extended error correction as a mark of robustness. E2C2.
- fweimer 3y ago
  It does, but this particular implementation is local to the module, and cannot be used for secondary purposes in addition to error correction, such as storing tag bits.
  - fbdab103 3y ago
    As a consumer does that matter? I understand server grade hardware wants the extra monitoring/diagnostic gizmos, but will the memory be corrected with the same efficiency as DDR4 ECC or is it an entirely neutered implementation?
    - ElectricalUnion 3y ago
      Not entirely neutered, but at least "data-at-rest" is protected, while "data-in-flight" is not.
      - fbdab103 3y ago
        Is there any intuition about how frequently data-at-rest errors occur vs data-in-flight? Would the native DDR5 ECC get me 90% of the way there or is it so minor as to be effectively meaningless? I assume it is going to take another decade to fully unwind Intel's ECC market segmentation. Trying to get a sense on if I should pay the ECC tax for my next build. Of course noting that as a consumer, I will probably never notice a flipped bit.
        lazide 3y ago
        You’d ‘notice’ the flipped bits usually as rare, random, and impossible to reproduce crashes and lockups with the occasional data corruption. Which is often background noise for home users, but no less problematic. Often heat/load dependent too.
ikekkdcjkfke 3y ago
All ddr5 has ecc
- pixl97 3y ago
  But it does not have a means of reporting ECC triggers to the user from my understanding, which is really one of the most important parts. When ECC starts tripping on a device outside of completely random times is when you should look into what's going wrong. You may have overheating or failing hardware.
drzaiusapelord 3y ago
Wikipedia: Unlike DDR4, all DDR5 chips have on-die ECC, where errors are detected and corrected before sending data to the CPU. This, however, is not the same as true ECC memory with extra data correction chips on the memory module. So I'm not sure how this works, because I'm not sure if "true" ECC is better/worse/same as on-die ECC. A casual googling shows on-die to have more advantages.
Keyframe 3y ago
I actually look forward to (promised) future where "disk" storage is fast enough not to need RAM anymore.
- brookst 3y ago
  The convergence of volatile and non-volatile storage is one of the most exciting upcoming technologies, and always will be.
  - Keyframe 3y ago
    yeah, it's a bit of fusion but for computing.. always 50 years out. Some day! Maybe.
- ls612 3y ago
  With the failure of Optane I doubt that it will be coming anytime soon.
- undersuit 3y ago
  The merging of CXL and NVME is just one frustrated vendor away.
hedora 3y ago
I think inline ECC (the module performs the ECC) is mandatory with LPDDR4 (the error rates on current silicon are too high to leave it out), but link ECC (between the CPU and the module) is optional. Note that link ECC + inline ECC don't give you end-to-end protection, since the controller in the memory module can still flip bits. DDR5 is moving to on-die ECC (which, unlike DDR <= 4's side-band ECC) also isn't end-to-end. I'd like to see side-band ECC continue to exist, but I think it is going to be phased out entirely. This article defines all the terms, but is very vague about what things are mandatory, or how reliable the error correction schemes are. For instance, it carefully doesn't say that SECDED schemes detect all two bit errors, instead it says they detect at least some: https://www.synopsys.com/designware-ip/technical-bulletin/error-correction-code-ddr.html https://www.synopsys.com/designware-ip/technical-bulletin/er...
- toast0 3y ago
  > I'd like to see side-band ECC continue to exist, but I think it is going to be phased out entirely. I doubt it will be phased out for servers. I haven't seen anyone reporting that on-die ECC in DDR5 has a reporting mechanism, and reporting on ram errors is important for server reliability.

bheadmaster 3y ago

Runtime asserts and invariant checks in software can also help a lot with isolating bitflip errors. With a nice addition of also isolating effects of software bugs.

mastax 3y ago
Assuming the compiler doesn't optimize them out.
gumby 3y ago
ECC is better handled in hardware: most of the time it won’t happen, and the hardware can more easily interrupt the processor so the kernel can correct the problem or signal a fault if it’s not a correctable corruption.
GuB-42 3y ago
I don't know if it is significant. Runtime checks tend to focus on small but critical part of the data, like size fields. It usually doesn't check bulk data, like decompressed image data, or code, and it also may not be effective if data is in cache. Furthermore, it will only detect errors, not correct them. Also the performance cost is, I think, much higher than the extra RAM chip. Good coding practice for critical path in software, but clearly, it doesn't substitute for dedicated hardware. I have had defective RAM, and I got quite a bit of corruption before the first crashes, it is hardly noticeable when it is just a pixel changing color in a picture, but it is still something you don't want. ECC would have prevented that. I know there is software resistant on random bitflips, like for satellites exposed to cosmic rays, but it is a highly specialized field. It is also a field where they use special chips, typically with coarser (and therefore less efficient) dies that are more resistant to radiation. You leave a lot on the table for that.
ElectricalUnion 3y ago
I thought that the current wave of compiler correctness checking, zero-cost abstractions, JIT compilers and speculative processor behaviour were all about removing those "unnecessary" runtime asserts and invariant checks to get better performance.
lazide 3y ago
Those only help isolate somewhat predictable errors. Which is rare for what ECC is designed to protect against. If it’s a random, once in several billion reads/writes issue, it can just stop/identify the bad data from further propagating. Sometimes. That data is still lost. ECC does forward error correction, which is extremely rare for the type of data protection you’re talking about. and if the data is corrupted in RAM (say when initially loaded/read) before the software can apply FEC, there is nothing the software can do.

Aurornis 3y ago

These are individual memory chips. They can be used to build both ECC modules and non-ECC modules. ECC modules just have more chips to store the extra parity information. In the high capacity RDIMM server market there are plenty of ECC options.

deleted 3y ago
[deleted]
spystath 3y ago
Oh yes, I understand that. I only wish that ECC support in general starts getting more traction in consumer electronics. Nowadays (unless you go to super noisy super expensive server hardware) maybe with an AMD processor maybe a motherboard manufacturer will have a 20-links-deep document that says that these ECC modules may be supported, proceed at your own risk, might set your flat on fire, kill kittens etc. When you had a couple of gigs of ram it was probably irrelevant but if you have multiple TB of RAM caching file access ECC should become normalised.
- Aurornis 3y ago
  ECC isn’t that hard to get in consumer platforms now. The situation has changed a lot from what you’re thinking. You can get ECC support on Intel 12th and 13th generation parts by buying a motherboard with a W680 chipset. You can get ECC support on modern AMD CPUs by picking a motherboard that lists ECC support listed on the product page. It’s not that hard.
  - rini17 3y ago
    And you can get reasonably priced notebook with ECC by...?
    - Aurornis 3y ago
      Lenovo has them. Again, not hard if you look. I know some people won’t be happy until every laptop has ECC RAM and is super cheap, but the reality is that the demand for ECC RAM is very low. The majority of users would choose the extra battery life and lower price if given the option.

bpye 3y ago

I really wish we’d just get in-band ECC on normal consumer platforms. That way we’d need no special DIMMs, in applications where ECC was desired it could be enabled and the capacity penalty would be paid, in other applications it could be disabled and no capacity would be lost.

gabereiser 3y ago
I like this idea. 64gb of ram non-ecc, 48gb in ecc. Dynamic, succinct, and enables more supply chain cross over for not having two (three?) separate DIMM types.
Aurornis 3y ago
Having physical memory segments be different logical sizes at runtime depending on the ECC setting does not sound fun. Having your system’s available memory fluctuate up and down based on how many segments are currently set to ECC also doesn’t sound fun. Having developers manually turn ECC off for regions where it’s unimportant sounds like a lot of complexity for a relatively rare use case. There is in-band ECC in some newer Intel designs, but it’s all or nothing. Adding extremely complexity to memory management to selectively disable it sounds like a lot to ask.
- gabereiser 3y ago
  I believe it would just be a kernel setting. Developers would just see full capacity or ecc-capacity, they wouldn’t care much why.
  - Aurornis 3y ago
    It’s implemented as a BIOS setting where it’s supported. But the parent comment was suggesting that it be on or off depending on the memory segment, which is a completely different problem.
    - saltcured 3y ago
      I don't see "segment" in the earlier post at all. I think your reading depends on thinking "application" means "process", while another reading would be that an application is a particular deployed system, where this setting can be altered e.g. at the BIOS level.

hinkley 3y ago

Doesn’t DDR5 require ECC to function properly? I think we’ve gotten to the point that we need extended error correction as a mark of robustness. E2C2.

fweimer 3y ago
It does, but this particular implementation is local to the module, and cannot be used for secondary purposes in addition to error correction, such as storing tag bits.
- fbdab103 3y ago
  As a consumer does that matter? I understand server grade hardware wants the extra monitoring/diagnostic gizmos, but will the memory be corrected with the same efficiency as DDR4 ECC or is it an entirely neutered implementation?
  - ElectricalUnion 3y ago
    Not entirely neutered, but at least "data-at-rest" is protected, while "data-in-flight" is not.
    - fbdab103 3y ago
      Is there any intuition about how frequently data-at-rest errors occur vs data-in-flight? Would the native DDR5 ECC get me 90% of the way there or is it so minor as to be effectively meaningless? I assume it is going to take another decade to fully unwind Intel's ECC market segmentation. Trying to get a sense on if I should pay the ECC tax for my next build. Of course noting that as a consumer, I will probably never notice a flipped bit.
      - lazide 3y ago
        You’d ‘notice’ the flipped bits usually as rare, random, and impossible to reproduce crashes and lockups with the occasional data corruption. Which is often background noise for home users, but no less problematic. Often heat/load dependent too.

ikekkdcjkfke 3y ago

All ddr5 has ecc

pixl97 3y ago
But it does not have a means of reporting ECC triggers to the user from my understanding, which is really one of the most important parts. When ECC starts tripping on a device outside of completely random times is when you should look into what's going wrong. You may have overheating or failing hardware.

drzaiusapelord 3y ago

Wikipedia: Unlike DDR4, all DDR5 chips have on-die ECC, where errors are detected and corrected before sending data to the CPU. This, however, is not the same as true ECC memory with extra data correction chips on the memory module. So I'm not sure how this works, because I'm not sure if "true" ECC is better/worse/same as on-die ECC. A casual googling shows on-die to have more advantages.

Keyframe 3y ago

I actually look forward to (promised) future where "disk" storage is fast enough not to need RAM anymore.

brookst 3y ago
The convergence of volatile and non-volatile storage is one of the most exciting upcoming technologies, and always will be.
- Keyframe 3y ago
  yeah, it's a bit of fusion but for computing.. always 50 years out. Some day! Maybe.
ls612 3y ago
With the failure of Optane I doubt that it will be coming anytime soon.
undersuit 3y ago
The merging of CXL and NVME is just one frustrated vendor away.

hedora 3y ago

I think inline ECC (the module performs the ECC) is mandatory with LPDDR4 (the error rates on current silicon are too high to leave it out), but link ECC (between the CPU and the module) is optional. Note that link ECC + inline ECC don't give you end-to-end protection, since the controller in the memory module can still flip bits. DDR5 is moving to on-die ECC (which, unlike DDR <= 4's side-band ECC) also isn't end-to-end. I'd like to see side-band ECC continue to exist, but I think it is going to be phased out entirely. This article defines all the terms, but is very vague about what things are mandatory, or how reliable the error correction schemes are. For instance, it carefully doesn't say that SECDED schemes detect all two bit errors, instead it says they detect at least some: https://www.synopsys.com/designware-ip/technical-bulletin/error-correction-code-ddr.html https://www.synopsys.com/designware-ip/technical-bulletin/er...

toast0 3y ago
> I'd like to see side-band ECC continue to exist, but I think it is going to be phased out entirely. I doubt it will be phased out for servers. I haven't seen anyone reporting that on-die ECC in DDR5 has a reporting mechanism, and reporting on ram errors is important for server reliability.