ECC matters • Hacker News Board

Re: ECC matters

#461

Post by sally1620 » Mon, Jan 04, 2021, 3:51 AM UTC

Linux is accusing Intel of killing ECC intentionally. But that is not really the case, they just wanted people to pay up.

If you care about ECC, you pay for Xeon. Majority of consumers don't run critical applications on their devices, so they are happy with a cheap device that may crash once in a while.

AMD is only changing the game because they are trying to undercut Intel. They have been putting pro features into all of their CPUs including over-clocking, extra PCIE lanes and ECC.

Honestly, what is the point of bullet-proof hardware when the software reliability (at least on consumer devices) has gone down to two nines.

Re: ECC matters

#462

Post by Animats » Mon, Jan 04, 2021, 3:57 AM UTC

jfim wrote: post #442

wolrah wrote: post #420

Earlier quoted context omitted.

I think they may have been referring to the actual mainstream retail availability of ECC RAM. I can buy non-ECC RAM at almost any retailer that sells computers. If I need non-ECC RAM right now I can have it in my hands in 30 minutes. ECC on the other hand I pretty much have to buy online. Microcenter stocks a single 4GB stick of PC4-21300, and I can't think of a single use case where I'd want ECC but not more than 4G…

You're right, rereading the parent post with that angle makes it clearer that they were complaining about the unavailability of memory and other hardware. It would definitely be great to have more reliable hardware generally available and at less of a price premium.

Yes. I'd pay an extra 25%, but not an extra 110%.

Re: ECC matters

#463

Post by [deleted] » Mon, Jan 04, 2021, 4:45 AM UTC

jandrese wrote: post #452

sitkack wrote: post #446

Earlier quoted context omitted.

The fact that ECC isn't the default across everything is a failure of human cognition and Capitalism.

I have always been angry that ECC was treated as an "enterprise" feature and increased the price way more than it should have.

[deleted]

Re: ECC matters

#464

Post by sneak » Mon, Jan 04, 2021, 4:45 AM UTC

jandrese wrote: post #452

sitkack wrote: post #446

Earlier quoted context omitted.

The fact that ECC isn't the default across everything is a failure of human cognition and Capitalism.

I have always been angry that ECC was treated as an "enterprise" feature and increased the price way more than it should have.

I feel this way about all software.

Re: ECC matters

#465

Post by srtjstjsj » Mon, Jan 04, 2021, 4:50 AM UTC

lostlogin wrote: post #366

koolba wrote: post #127

Earlier quoted context omitted.

SFF?

The Intel Nuc and Mac mini are good examples of this - however the Nuc doesn’t have its psu inside, it’s a brick. Great for fixing failures, horrible in general as a built in psu is so much tidier.

Internal PSU adds heat that is noisy or expensive to dissipate or is avoided by throttling performance.

Re: ECC matters

#466

Post by srtjstjsj » Mon, Jan 04, 2021, 4:58 AM UTC

I guess Linus's recent project to communicate more respectfully didn't pan out.

Re: ECC matters

#467

Post by fomine3 » Mon, Jan 04, 2021, 5:00 AM UTC

sally1620 wrote: post #461

Linux is accusing Intel of killing ECC intentionally. But that is not really the case, they just wanted people to pay up. If you care about ECC, you pay for Xeon. Majority of consumers don't run critical applications on their devices, so they are happy with a cheap device that may crash once in a while. AMD is only changing the game because they are trying to undercut Intel. They have been putting pro features into a…

ECC isn't enough to be bulletproof but improves reliability for well known relatively unreliable parts. Extra theoretical cost for ECC should be accepted for most of computer users. It also helps developing cheaper RAM technology (see what's happened on SSD).

Re: ECC matters

#468

Post by srtjstjsj » Mon, Jan 04, 2021, 5:01 AM UTC

apankrat wrote: post #379

cbanek wrote: post #77

As someone who has had to read thousands of random game crash reports from all over the interwebs (you know when Windows says you might want to send that crash log? like that), I totally agree. Of all the things to be worried about, like OS bugs, bad hardware configuration, etc. bad memory is one of those really troubling things. You look at the code and say "it's can't make it here, because this was set" but when yo…

Aye. I have an assert in the code that fronts a very pedantic test of the context. In all cases when this assert was tripped (and reported) an overnight memtest86 test surfaced RAM issues. - Edit - Also, bit flips in the non-ECC memory are _the_ cause of the "bitrot" phenomenon. That is when you write out X to a storage device, but you get Y when you read it back. A common explanation is that the corruption happens _…

Bitrot in human memory is the same. Memories change during the process of recalling them, not while they are in "storage".

Re: ECC matters

#469

Post by fomine3 » Mon, Jan 04, 2021, 5:04 AM UTC

toast0 wrote: post #324

FartyMcFarter wrote: post #139

Does anyone know why ECC memory requires the CPU to support it? Naively, I can understand why error reporting has dependencies on other parts of the system, but it would seem possible for error correction to work transparently.

As implemented today, ECC is a feature of the memory controller. You need special ram, because instead of 8 parallel rams per bank, you need 9, and all the extra data lines to go to the controller. Modern CPUs have integrated memory controllers, so that's why the CPU needs to support it. Correction without reporting isn't great; anyway, you need a reporting mechanism for uncorrectable errors, or all you've done is en…

Error correcting and reporting is better, but even only correcting is better than non-ECC. I wonder this compromise could be accepted by Intel.

Re: ECC matters

#470

Post by scottlamb » Mon, Jan 04, 2021, 5:27 AM UTC

linsomniac wrote: post #357

This reminds me of last year we ordered a new $14K server, it arrived and we ran it through our burn-in process which included running memtest86 on it, and it would, after around 7 hours, generate errors. Support was only interested if their built-in memory tester, which even on it's most thorough, would only run for ~3 hours, would show errors, which it wouldn't. IIRC, the BMC was logging "correctable memory errors"…

> They were all too willing to have us go to production relying on ECC to handle the memory error.

Good call in not accepting this. Even ignoring the possibility you have a double-bit error that causes a crash, or a triple-bit error that maybe can't be detected, frequent ECC errors are problematic. I've encountered machines that consistently ran my software horribly slowly. I don't remember specifics, but let's say at least 100X latency of other machines for similar operations. When I dug in, I found these machines had a huge amount of correctable memory errors. The correction apparently degrades performance significantly. I'm not sure exactly why, but I guess there's an MCE trap to report the memory error, and perhaps that path is slow.