Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

ECC and DDR5

etbe.coker.com.au

Post reply on HN
Print view View original

21–30 of 162 posts

Re: ECC and DDR5

#21

Post by Wowfunhappy »

zargon wrote: post #18
cyanmagenta wrote: post #16

Earlier quoted context omitted.

Right. Everyone agrees that real ECC is more robust, and production servers of course run it. But it seems to me that if most RAM bitflips are in the module itself (rather than in transmission to CPU), then on-die ECC could in theory make the probability of a bitflip in practice so low that for things like home servers it isn’t worth the price premium for real ECC. But without data on this, everyone is just speculati…

This is the attitude that needs to change. If RAM is 25% of the system cost (say for a home server in your example), then the cost for ECC is 3% of the system cost. There is no world where accepting data corruption in order to save 3% cost is a reasonable tradeoff. ECC should be standard, period.

When I last looked at this (a couple of years ago), it wasn't just the cost difference—the ECC memory available to purchase was also slower than non-ECC offerings, or at least cost significantly more if I actually wanted the same speed. At least for me, going ECC simply didn't make sense.

Caveat that I was building a gaming PC at that time, I might have gone differently for a home server. And, this was before the memory market went nuts for unrelated reasons.

Re: ECC and DDR5

#22

Post by inigyou »

nahuel0x wrote: post #3

Something important not discussed here is that you need not only error correction (when possible) but also error reporting, so you can know you RAM is failing. Sadly, is not possible to get DDR5 on-die ECC error counts reported to the OS. Alternative solution, use IBECC with DDR5, where the CPU reserves a portion of the RAM for parity bits and does the check / reporting.

My Linux installation came with an AMD MCE driver that reports them to dmesg. It logs a few corrected errors a day.

Re: ECC and DDR5

#23

Post by inigyou »

lightedman wrote: post #8

"Ideally we would have some government action to force this given the ongoing cost to society in corrupted data" Why is it so often Australia with the "We must force unnecessary things upon people" attitude?

How is it unnecessary. Australia has tons of laws about faulty products. All developed countries do

Re: ECC and DDR5

#24

Post by adrian_b »

cyanmagenta wrote: post #16
phkahler wrote: post #10

Earlier quoted context omitted.

>> Everyone repeats the statement DDR5 on-die ECC isn’t a replacement for regular ECC, but nobody ever shows data on DDR5 bitflips. That's because the on-die ECC cannot detect errors in the transmission of data from the DIMMs to the CPU. It seems like on-die ECC is meant to "hide" some level of errors to make less reliable RAM chips appear good. I have no idea if that's a reasonable way to do it, but it seems like it…

Right. Everyone agrees that real ECC is more robust, and production servers of course run it. But it seems to me that if most RAM bitflips are in the module itself (rather than in transmission to CPU), then on-die ECC could in theory make the probability of a bitflip in practice so low that for things like home servers it isn’t worth the price premium for real ECC. But without data on this, everyone is just speculati…

No.

On-die ECC was added in DDR5 because the error frequency has increased too much.

Its only effect was that now DDR5, as seen externally, has a reliability similar to that of the older memory generations. On-die ECChas not brought any serious improvement in reliability. It has just prevented the degradation of the reliability.

The errors generated internally are caused mostly by the ionizing radiation from the environment, which discharges the storage capacitors.

However there are many errors that appear during the communication between memories and the CPU, which are caused by the electrical noise from the environment.

These external errors are much less likely to appear for soldered DRAM. Because of this, for soldered LPDDRx memory it is less important to have end-to-end ECC than for socketed modules, which are much more vulnerable to noise.

The DDR5 standard has some options for using some error detection for the communication link, but it is impossible to know whether a given computer or motherboard has implemented such options or if they are enabled by the firmware when the motherboard has the physical support.

The only way to be certain that the memory works fine is to use ECC that covers completely the circuit from the CPU memory controller to the values stored in the DRAM and back to the CPU memory controller and your operating system has the appropriate device driver for obtaining the error reports.

Re: ECC and DDR5

#25

Post by adrian_b »

Wowfunhappy wrote: post #21
zargon wrote: post #18

Earlier quoted context omitted.

This is the attitude that needs to change. If RAM is 25% of the system cost (say for a home server in your example), then the cost for ECC is 3% of the system cost. There is no world where accepting data corruption in order to save 3% cost is a reasonable tradeoff. ECC should be standard, period.

When I last looked at this (a couple of years ago), it wasn't just the cost difference—the ECC memory available to purchase was also slower than non-ECC offerings, or at least cost significantly more if I actually wanted the same speed. At least for me, going ECC simply didn't make sense. Caveat that I was building a gaming PC at that time, I might have gone differently for a home server. And, this was before the mem…

Yes, ECC DIMMs are available only for the memory speeds guaranteed to work by the manufacturers of CPUs, like Intel and AMD, e.g. for up to DDR5-5600 in UDIMMs or DDR5-6400 in RDIMMs.

The "gaming" DIMMs are available in much greater speeds, which are "overclocked" speeds, i.e. there exists absolutely no guarantee from Intel or AMD that they work at the advertised speed, even if they frequently do work.

However, with such overclocked DIMMs, you do not know how well they work. They might work most of the time, but e.g. in a hotter room they might have an error or two per day without you noticing, especially if the computer is used mainly for games.

For someone doing anything professional on a computer, overclocked DIMMs are not an acceptable choice.

Re: ECC and DDR5

#26

Post by Marsymars »

adrian_b wrote: post #24
cyanmagenta wrote: post #16

Earlier quoted context omitted.

Right. Everyone agrees that real ECC is more robust, and production servers of course run it. But it seems to me that if most RAM bitflips are in the module itself (rather than in transmission to CPU), then on-die ECC could in theory make the probability of a bitflip in practice so low that for things like home servers it isn’t worth the price premium for real ECC. But without data on this, everyone is just speculati…

No. On-die ECC was added in DDR5 because the error frequency has increased too much. Its only effect was that now DDR5, as seen externally, has a reliability similar to that of the older memory generations. On-die ECChas not brought any serious improvement in reliability. It has just prevented the degradation of the reliability. The errors generated internally are caused mostly by the ionizing radiation from the envi…

Also to note, asides from the physical differences, LPDDR5+ also features link ECC.

Re: ECC and DDR5

#27

Post by tbrownaw »

zargon wrote: post #18
cyanmagenta wrote: post #16

Earlier quoted context omitted.

Right. Everyone agrees that real ECC is more robust, and production servers of course run it. But it seems to me that if most RAM bitflips are in the module itself (rather than in transmission to CPU), then on-die ECC could in theory make the probability of a bitflip in practice so low that for things like home servers it isn’t worth the price premium for real ECC. But without data on this, everyone is just speculati…

This is the attitude that needs to change. If RAM is 25% of the system cost (say for a home server in your example), then the cost for ECC is 3% of the system cost. There is no world where accepting data corruption in order to save 3% cost is a reasonable tradeoff. ECC should be standard, period.

> There is no world where accepting data corruption in order to save 3% cost is a reasonable tradeoff.

It is if you're doing something where corruption is detectable after the fact, and happens rarely enough that redoing affected work adds less than 3% overhead.

Re: ECC and DDR5

#28

Post by rubatuga »

inigyou wrote: post #22
nahuel0x wrote: post #3

Something important not discussed here is that you need not only error correction (when possible) but also error reporting, so you can know you RAM is failing. Sadly, is not possible to get DDR5 on-die ECC error counts reported to the OS. Alternative solution, use IBECC with DDR5, where the CPU reserves a portion of the RAM for parity bits and does the check / reporting.

My Linux installation came with an AMD MCE driver that reports them to dmesg. It logs a few corrected errors a day.

Isn't that a lot? I see them only when heavily over clocking .

Re: ECC and DDR5

#29

Post by adrian_b »

lightedman wrote: post #8

"Ideally we would have some government action to force this given the ongoing cost to society in corrupted data" Why is it so often Australia with the "We must force unnecessary things upon people" attitude?

This would be a consumer protection law like any other such law.

Forcing the vendors to sell only products that do what they are advertised cannot be considered in any way as "forcing unnecessary things upon people".

Any computer without ECC memory is a computer that does not compute from time to time and you have no idea when that happens.

Originally, any IBM PC or compatible had memory error detection.

All this problem of the computers without ECC memory has been created by some evil Intel employees, who have conceived around 1994 a scheme for market segmentation between "Pentium" and "Pentium Pro".

So they removed memory error detection support from the Pentium chipsets (Intel Triton), so that this would remain a marketing feature exclusive to the "Pro" Intel products.

Obviously the removal of this feature from "consumer" products was done without any price reduction, which made happy also the memory vendors, because this trick increased their profits.

So in the next years this market segmentation method became the "standard" business practice, preying on the naivety of most computer users.

A consumer protection law should force that any computer or motherboard must support ECC, which adds a completely negligible cost.

The end users may buy non-ECC modules, if they choose so, but non-ECC modules should be sold like cigarettes, with a visible advertisement that using such modules may cause unpredictable errors in your computer.

Re: ECC and DDR5

#30

Post by _factor »

some_random wrote: post #14
lightedman wrote: post #8

"Ideally we would have some government action to force this given the ongoing cost to society in corrupted data" Why is it so often Australia with the "We must force unnecessary things upon people" attitude?

I think it's a pattern that reinforces itself, as a nanny state develops it's opinion of it's people worsens and it's more willing to use force to compel them.

Right, the opinion shifting to the people being unworthy of uncorrupted data unless they’re wealthy enough to pay the artificial extortion price for integrity.
Post reply on HN