By: wumpus (wumpus.delete.delete.delete@this.this.this.lost.in.a.hole), April 7, 2021 9:06 am
Room: Moderated Discussions
Doug S (foo.delete@this.bar.bar) on April 5, 2021 6:57 am wrote:
> David Hess (davidwhess.delete@this.gmail.com) on April 4, 2021 8:45 pm wrote:
> > This also means that the external overhead of ECC is greater going from 64/72 to 32/40,
> > but maybe the internal organization is different for the mandatory internal ECC.
>
>
> Given that full ECC for DDR5 will (at least) double the ECC DIMM price penalty I wouldn't be
> surprised to see some using DDR5's internal ECC as an excuse to drop board support for it. Fewer
> customers will demand it due to the higher cost, and marketing will be telling those customers
> "its built into the DIMMs now, you don't need ECC except at the extreme high end".
>
You only need it if you are worried about the entire chip frying at once. But plenty of the people who wanted ECC will still want parity (possibly a multi-bit checksum). If the data gets mangled in the I/O interface you want to know. You can still pull the known-good data from the ECC DRAM with a repeat, but you have to know the error occurred (through parity) before you will do that.
I have to wonder just how much of the market is worried enough about a single chip frying to use double-ECC but not sufficiently concerned about the rest of the server to effectively duplicate entire server racks. There are a lot more single point of failures than DRAM, it is just that DRAM errors are more common (without internal ECC) and easier to deal with, so I suspect that *that guy* in the engineering design review will force them to use double-ECC "because you can't be too careful".
PS. Logically, you could use a single bit carry-chain across "n" chips for a "n-burst" read that would deliver the parity for the entire read at the end of the cycle. Cost would be two pins. Somehow I doubt anyone would bother for DDR-6.
> David Hess (davidwhess.delete@this.gmail.com) on April 4, 2021 8:45 pm wrote:
> > This also means that the external overhead of ECC is greater going from 64/72 to 32/40,
> > but maybe the internal organization is different for the mandatory internal ECC.
>
>
> Given that full ECC for DDR5 will (at least) double the ECC DIMM price penalty I wouldn't be
> surprised to see some using DDR5's internal ECC as an excuse to drop board support for it. Fewer
> customers will demand it due to the higher cost, and marketing will be telling those customers
> "its built into the DIMMs now, you don't need ECC except at the extreme high end".
>
You only need it if you are worried about the entire chip frying at once. But plenty of the people who wanted ECC will still want parity (possibly a multi-bit checksum). If the data gets mangled in the I/O interface you want to know. You can still pull the known-good data from the ECC DRAM with a repeat, but you have to know the error occurred (through parity) before you will do that.
I have to wonder just how much of the market is worried enough about a single chip frying to use double-ECC but not sufficiently concerned about the rest of the server to effectively duplicate entire server racks. There are a lot more single point of failures than DRAM, it is just that DRAM errors are more common (without internal ECC) and easier to deal with, so I suspect that *that guy* in the engineering design review will force them to use double-ECC "because you can't be too careful".
PS. Logically, you could use a single bit carry-chain across "n" chips for a "n-burst" read that would deliver the parity for the entire read at the end of the cycle. Cost would be two pins. Somehow I doubt anyone would bother for DDR-6.