3 ms·

> SECDED requires 39. I don't know if the 40th bit is used for anything? FWIW this is completely up to the CPU. "Classical" ECC is completely transparent to th

> SECDED requires 39. I don't know if the 40th bit is used for anything? FWIW this is completely up to the CPU. "Classical" ECC is completely transparent to the DIMM, it just remembers and returns what the CPU gave to it. 32 → 40 has already been around for quite some time (particularly when the DDR controller only has 64 data lines but you still want ECC you can sometimes do 32+8 at half performance & max capacity) but I don't see anything beyond SECDED in the datasheets... (looked through some Freescale/NXP PowerPC bits)

Dylan16807 5y ago
> FWIW this is completely up to the CPU. "Classical" ECC is completely transparent to the DIMM, it just remembers and returns what the CPU gave to it. True, but I guess I assumed normal ECC was standardized. Is it? > 32 → 40 has already been around for quite some time (particularly when the DDR controller only has 64 data lines but you still want ECC Is that keeping a burst length of 8 on DDR3/DDR4? One thing to consider is that a full memory transfer plus 16 extra bits is much more useful than a smaller transfer with 8 extra bits. That could easily be a tipping point from "not worth bothering" to "they really should do something here".
- eqvinox 5y ago
  > True, but I guess I assumed normal ECC was standardized. Is it? This is outside my area of expertise, but I believe everyone just does the same thing without it being a standard. (Especially since even CPU vendors frequently just buy a done-and-tested DDR controller design.) > Is that keeping a burst length of 8 on DDR3/DDR4? All the "classical" ECC just uses additional data lines, and I assumed DDR5 would do the same thing. I hadn't checked until a minute ago, but yes, DDR5 (like previous versions) just extends the width of the data bus by the ECC bits.
  - Dylan16807 5y ago
    > All the "classical" ECC just uses additional data lines I know that. But DDR5, at least under normal use, increases the number of bits sent across each data line in a single memory access. So now you have 16 spare bits across the entire thing, instead of just 8. This means that even if you had 32->40 ECC before, the value you could extract from the extra bits goes up a lot with DDR5.
    - eqvinox 5y ago
      Oh, sorry, I misunderstood. I don't think any implementation does that, since it would require holding back the entire burst in a buffer in the DDR controller. Which would significantly impact performance through the added latency. But honestly I don't know — and also this seems like if some vendor wanted to take (or not take) the performance hit for extra safety, they could well deviate from everyone else.
      - Dylan16807 5y ago
        To be 100% safe, it would add latency to part of the reads. Though not much compared to the normal speed of a memory access. To be 99% safe you could send a signal a couple nanoseconds late that says "wait, this data is bad, you should abort". It also might make writes a bit more awkward.

Dylan16807 5y ago

> FWIW this is completely up to the CPU. "Classical" ECC is completely transparent to the DIMM, it just remembers and returns what the CPU gave to it. True, but I guess I assumed normal ECC was standardized. Is it? > 32 → 40 has already been around for quite some time (particularly when the DDR controller only has 64 data lines but you still want ECC Is that keeping a burst length of 8 on DDR3/DDR4? One thing to consider is that a full memory transfer plus 16 extra bits is much more useful than a smaller transfer with 8 extra bits. That could easily be a tipping point from "not worth bothering" to "they really should do something here".

eqvinox 5y ago
> True, but I guess I assumed normal ECC was standardized. Is it? This is outside my area of expertise, but I believe everyone just does the same thing without it being a standard. (Especially since even CPU vendors frequently just buy a done-and-tested DDR controller design.) > Is that keeping a burst length of 8 on DDR3/DDR4? All the "classical" ECC just uses additional data lines, and I assumed DDR5 would do the same thing. I hadn't checked until a minute ago, but yes, DDR5 (like previous versions) just extends the width of the data bus by the ECC bits.
- Dylan16807 5y ago
  > All the "classical" ECC just uses additional data lines I know that. But DDR5, at least under normal use, increases the number of bits sent across each data line in a single memory access. So now you have 16 spare bits across the entire thing, instead of just 8. This means that even if you had 32->40 ECC before, the value you could extract from the extra bits goes up a lot with DDR5.
  - eqvinox 5y ago
    Oh, sorry, I misunderstood. I don't think any implementation does that, since it would require holding back the entire burst in a buffer in the DDR controller. Which would significantly impact performance through the added latency. But honestly I don't know — and also this seems like if some vendor wanted to take (or not take) the performance hit for extra safety, they could well deviate from everyone else.
    - Dylan16807 5y ago
      To be 100% safe, it would add latency to part of the reads. Though not much compared to the normal speed of a memory access. To be 99% safe you could send a signal a couple nanoseconds late that says "wait, this data is bad, you should abort". It also might make writes a bit more awkward.