4 ms·
> 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
by 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 agoOh, 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 agoTo 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.