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

ECC matters

realworldtech.com

Post reply on HN
Print view View original

261–270 of 567 posts

Re: ECC matters

#261

Post by dijit »

jkbbwr wrote: post #90
dijit wrote: post #25

Earlier quoted context omitted.

There are situations though, where you’re working on a document and the documents “save” format is a memory dump. Corruption for things of that type (Adobe RAW for example) would remove data. It might present itself as a 1pixel colour difference, but it could be more damaging (incorrect finances, in accounting software for example). Software trusts memory; but memory can lie. That’s dangerous.

To be fair, if your save mechanism is just a straight memory dump with no checksums and validation. You have bigger issues.

That happens more than you think though. Most* things that output PNG are making an in-memory data structure and dumping it to disk.

Re: ECC matters

#262

Post by CalChris »

loeg wrote: post #33
dijit wrote: post #16

I beg this, every time this conversation comes up it’s the same answer “I don’t see a problem”. It’s so easy to chalk these kind of errors to other issues, a little corruption here, a running program goes bezerk there- could be a buggy program or a little accidental memory overwrite. Reboot will fix it. But I ran many thousands of physical machines, petabytes of RAM, I tracked memory flip errors and they were _common…

Yeah, it's real obnoxious of Intel to silo ECC support off into the Xeon line, isn't it? I switched to ECC memory in 2013 or 2014 with a Xeon E3 (fundamentally a Core i7 without the ECC support fused off) and of course a Xeon-supporting motherboard (with weird "server board" quirks: e.g., no on-board sound device). I love that AMD doesn't intentionally break ECC on its consumer desktop platforms and upgraded to the T…

Yeah, the iMac Pro has the Xeon W and ECC. T'would be nice if the Apple Silicon MacBook Pro had it. There's not much of a reason to pay for the Pro over the Air. But like Linus, I'm going to blame Intel for this situation in the market. Maybe Apple will strike out on its own with Apple Silicon but since their dominant use case is phones, I'll not hold my breath.

Re: ECC matters

#263

Post by mlyle »

derefr wrote: post #168
dijit wrote: post #16

I beg this, every time this conversation comes up it’s the same answer “I don’t see a problem”. It’s so easy to chalk these kind of errors to other issues, a little corruption here, a running program goes bezerk there- could be a buggy program or a little accidental memory overwrite. Reboot will fix it. But I ran many thousands of physical machines, petabytes of RAM, I tracked memory flip errors and they were _common…

Were you around for enough DRAM generations to notice an effect of DRAM density / cell-size on reported ECC error rate? I’ve always believed that, ECC aside, DRAM made intentionally with big cells would be less prone to spurious bit-flips (and that this is one of the things NASA means when they talk about “radiation hardening” a computer: sourcing memory with ungodly-large DRAM cells, willingly trading off lower memo…

I think it's been quadratic with a pretty low contribution from the order 2 term.

Think of the number of events that can flip a bit. If you make bits smaller, you get a modestly larger number of events in a given area capable of flipping a bit, spread across a larger number of bits in that area.

That is, it's flip event rate * memory die area, not flip event rate * number of memory bits.

In recent generations, I understand it's even been a bit paradoxical-- smaller geometries mean less of the die is actual memory bits, so you can actually end up with fewer flips from shrinking geometries.

And sure, your other effect is true: there's a whole lot fewer bitflips that "matter". Flip a bit in some framebuffer used in compositing somewhere-- and that's a lot of my memory-- and I don't care.

Re: ECC matters

#264

Post by MaxBarraclough »

knorker wrote: post #252
KingMachiavelli wrote: post #160

Earlier quoted context omitted.

Well maybe. Rather than having to trust memory completely, it would just be better to use a binary format where each bit is verifiable so then at least a single bit flip would be immediately obvious. For example, a bit flip in a TLS session causes the whole session to fail rather than a random page element to change.

That doesn't help if the memory is corrupted before the verification code is applied. (the code will simply put a signature on incorrect data) Or after it's been checked. (time-of-check vs time-of-use)

Right, exactly. TCP protects us from data-corruption in network streams, and ECC protects us from data-corruption in RAM. I doubt any sort of software solution could practically compete against hardware ECC, even if it could be done it would presumably be disastrous for performance.

Re: ECC matters

#265

Post by vbezhenar »

loeg wrote: post #33
dijit wrote: post #16

I beg this, every time this conversation comes up it’s the same answer “I don’t see a problem”. It’s so easy to chalk these kind of errors to other issues, a little corruption here, a running program goes bezerk there- could be a buggy program or a little accidental memory overwrite. Reboot will fix it. But I ran many thousands of physical machines, petabytes of RAM, I tracked memory flip errors and they were _common…

Yeah, it's real obnoxious of Intel to silo ECC support off into the Xeon line, isn't it? I switched to ECC memory in 2013 or 2014 with a Xeon E3 (fundamentally a Core i7 without the ECC support fused off) and of course a Xeon-supporting motherboard (with weird "server board" quirks: e.g., no on-board sound device). I love that AMD doesn't intentionally break ECC on its consumer desktop platforms and upgraded to the T…

You can find non-Xeons with ECC support. But they are rare and usually suitable for some kinds of micro servers.

Re: ECC matters

#266

Post by IanCutress »

ratiolat wrote: post #224

I have: Asus PRIME A520M-K Motherboard 2x M391A2K43DB1-CVF (Samsung 16GiB ECC Unbuffered RAM) AMD Ryzen 5 3600 I specifically was looking for bang for buck, low(er) wattage and ECC.

Those AMD motherboards with consumer CPUs are a bit iffy. They run ECC memory, but it's hard to tell if it is running in ECC mode. Even some of the tools that identify ECC is running will say it is, even when it isn't, because the motherboard will report it is, even when it isn't. ECC isn't a qualified metric on the consumer boards, hence all the confusion.

Re: ECC matters

#268

Post by knorker »

MaxBarraclough wrote: post #264
knorker wrote: post #252

Earlier quoted context omitted.

That doesn't help if the memory is corrupted before the verification code is applied. (the code will simply put a signature on incorrect data) Or after it's been checked. (time-of-check vs time-of-use)

Right, exactly. TCP protects us from data-corruption in network streams, and ECC protects us from data-corruption in RAM. I doubt any sort of software solution could practically compete against hardware ECC, even if it could be done it would presumably be disastrous for performance.

The best integrity checking is "end to end". The problem with non-ECC is that there are no "ends" that are trustworthy.

I guess in theory some software could produce signed data in CPU cache, and "commit" it to RAM as a verified block.

But the overhead would be enormous. Would you slow down your CPU by half in order to not pay 12.5% more for RAM?

Hmm, I wonder what SGX and similar do about this.

Re: ECC matters

#269

Post by cududa »

mlyle wrote: post #200
cududa wrote: post #145

Earlier quoted context omitted.

Huh? Why would the memory controller not be updated accordingly? Also I have no idea about Linux or Mac, but Windows has had ECC support and active management for decades?

Normally, ECC has meant just the DIMM stores some extra bits, and the memory controller itself implements ECC-- writing the extra parity, and recovering when errors emerge (and halting when non-recoverable errors happen). DDR5 includes on-die ECC, where the RAM fixes the errors before sending them over the memory bus. This means if the bus between the processor and ram corrupts the bits-- tough luck, they're still co…

Thank you!
Post reply on HN