3 ms·

It is little better than speculation but the photo shown suggests 9 bits.

wtallis 3y ago
5 columns of chips on each side indicates an extra 8 bits for each 32-bit subchannel, which is pretty common for DDR5 RDIMMs. But the article mentions a 72-bit interface (the standard for DDR5 ECC UDIMMs and earlier ECC DIMM standards) rather than an 80-bit interface, so there's at least some cause for doubt about which level of ECC these modules provide.
- Dylan16807 3y ago
  > a 72-bit interface (the standard for DDR5 ECC UDIMMs How does that work, when you only have 4 bits of ECC per 32 bits of data? Is the calculation done in two-transfer bursts? (Apparently EC4 and EC8 are useful keywords for this.)
  - wmf 3y ago
    DDR5 uses burst length 16, so think of it as 512 data bits with 64 ECC bits out of 576 total.
    - Dylan16807 3y ago
      Sure, it is, but that doesn't explain how it works. Previous generations made it simple, they did SECDED ECC (or sometimes chipkill) one transfer at a time no matter what the transaction size was. DDR5 EC4 can't do that, so what does it do? And does EC8 do SECDED one transfer at a time, or does it do something more resilient? (And sure technically it's up to the memory controller to implement, but are different controllers doing different things with DDR5?)
      - wmf 3y ago
        72-bit DDR5 is nonstandard to begin with and I assume AMD and Intel are using undocumented ECC codes. There might be hints in patents.
- candiddevmike 3y ago
  AIUI, I don't think folks will be able to read the ECC values from these chips. They may/should silently fix issues but you won't be able to monitor the chips like you can with regular ECC RAM using tools like ras. So they may help with bit flips but won't help identifying bad sticks, I think.
  - wtallis 3y ago
    The ECC used by buffered modules is the "regular ECC RAM" where the memory bus is widened (and chip count increased) to accommodate carrying the extra ECC information between the DRAM controller on the CPU and the memory modules, with the ECC calculations and corrections done on the CPU and errors surfaced to the firmware and/or OS, giving ECC protection not just for data at rest but also in transit. But the actual ECC bits computed, transferred and stored for each word of DRAM are never directly exposed to software to access. There is also on-die ECC used by all recent DRAM as a consequence of shrinking memory cell sizes and spacing in the latest DRAM fabrication processes. That on-die ECC is what's unfortunately invisible to the host system, and only really useful for protecting data at rest, not in transit. The existence of on-die ECC has most commonly been publicized in the context of DDR5, but really has nothing to do with what DRAM interface standard is used because the on-die ECC happens entirely on each individual die.
    - Dylan16807 3y ago
      > only really useful for protecting data at rest, not in transit Which makes it more annoying that normal DDR doesn't also have the ability to add link-ECC like LPDDR.

5 columns of chips on each side indicates an extra 8 bits for each 32-bit subchannel, which is pretty common for DDR5 RDIMMs. But the article mentions a 72-bit interface (the standard for DDR5 ECC UDIMMs and earlier ECC DIMM standards) rather than an 80-bit interface, so there's at least some cause for doubt about which level of ECC these modules provide.

Dylan16807 3y ago
> a 72-bit interface (the standard for DDR5 ECC UDIMMs How does that work, when you only have 4 bits of ECC per 32 bits of data? Is the calculation done in two-transfer bursts? (Apparently EC4 and EC8 are useful keywords for this.)
- wmf 3y ago
  DDR5 uses burst length 16, so think of it as 512 data bits with 64 ECC bits out of 576 total.
  - Dylan16807 3y ago
    Sure, it is, but that doesn't explain how it works. Previous generations made it simple, they did SECDED ECC (or sometimes chipkill) one transfer at a time no matter what the transaction size was. DDR5 EC4 can't do that, so what does it do? And does EC8 do SECDED one transfer at a time, or does it do something more resilient? (And sure technically it's up to the memory controller to implement, but are different controllers doing different things with DDR5?)
    - wmf 3y ago
      72-bit DDR5 is nonstandard to begin with and I assume AMD and Intel are using undocumented ECC codes. There might be hints in patents.
candiddevmike 3y ago
AIUI, I don't think folks will be able to read the ECC values from these chips. They may/should silently fix issues but you won't be able to monitor the chips like you can with regular ECC RAM using tools like ras. So they may help with bit flips but won't help identifying bad sticks, I think.
- wtallis 3y ago
  The ECC used by buffered modules is the "regular ECC RAM" where the memory bus is widened (and chip count increased) to accommodate carrying the extra ECC information between the DRAM controller on the CPU and the memory modules, with the ECC calculations and corrections done on the CPU and errors surfaced to the firmware and/or OS, giving ECC protection not just for data at rest but also in transit. But the actual ECC bits computed, transferred and stored for each word of DRAM are never directly exposed to software to access. There is also on-die ECC used by all recent DRAM as a consequence of shrinking memory cell sizes and spacing in the latest DRAM fabrication processes. That on-die ECC is what's unfortunately invisible to the host system, and only really useful for protecting data at rest, not in transit. The existence of on-die ECC has most commonly been publicized in the context of DDR5, but really has nothing to do with what DRAM interface standard is used because the on-die ECC happens entirely on each individual die.
  - Dylan16807 3y ago
    > only really useful for protecting data at rest, not in transit Which makes it more annoying that normal DDR doesn't also have the ability to add link-ECC like LPDDR.