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

101–110 of 567 posts

Re: ECC matters

#101

Post by jackric »

faitswulff wrote: post #95
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…

Do the crash reports include whether the machine has ECC memory?

Do the crash reports include recent solar activity?

Re: ECC matters

#102

Post by andi999 »

simias wrote: post #26
IgorPartola wrote: post #18

Earlier quoted context omitted.

To someone on HN who isn’t familiar with what ECC does that explains nothing about how ECC works and how it could have prevented these situations. Or how often they really happen.

The problem is that, if you don't have ECC to detect the errors, it's very hard to know what exactly caused a random, non-reproducible crash. Especially in kernel mode where there's little memory protection and basically any driver could be writing anywhere at any time. I can understand Linus's frustration from that point of view: without ECC RAM when you get some super weird crash report where some pointer got corru…

You could run memtest on a pc without ecc for a couple of days and to estimate the error rate, or not?

Re: ECC matters

#103

Post by Triv888 »

faitswulff wrote: post #95
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…

Do the crash reports include whether the machine has ECC memory?

most gaming desktops don't use ECC RAM anyways (at least those from a few years ago)

Re: ECC matters

#104

Post by jacquesm »

faitswulff wrote: post #95
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…

Do the crash reports include whether the machine has ECC memory?

On intel consumer boxes it is pretty safe to assume that they don't, on AMD it might be the case but it usually isn't.

Re: ECC matters

#106

Post by chalst »

IgorPartola wrote: post #18
eloy wrote: post #5

Earlier quoted context omitted.

He does explain it: > We have decades of odd random kernel oopses that could never be explained and were likely due to bad memory. And if it causes a kernel oops, I can guarantee that there are several orders of magnitude more cases where it just caused a bit-flip that just never ended up being so critical. It might be false, but I think it's a reasonable assumption.

To someone on HN who isn’t familiar with what ECC does that explains nothing about how ECC works and how it could have prevented these situations. Or how often they really happen.

From https://en.m.wikipedia.org/wiki/ECC_memory -

> A large-scale study based on Google's very large number of servers was presented at the SIGMETRICS/Performance ’09 conference.[6] The actual error rate found was several orders of magnitude higher than the previous small-scale or laboratory studies, with between 25,000 (2.5 × 10−11 error/bit·h) and 70,000 (7.0 × 10−11 error/bit·h, or 1 bit error per gigabyte of RAM per 1.8 hours) errors per billion device hours per megabit. More than 8% of DIMM memory modules were affected by errors per year

Re: ECC matters

#107

Post by jacquesm »

kensai wrote: post #2

“ECC availability matters a lot - exactly because Intel has been instrumental in killing the whole ECC industry with it's horribly bad market segmentation.” Its. There, I finally corrected Linus Torvalds in something. :))

How is your Finnish?

Re: ECC matters

#108

Post by bradfa »

zdw wrote: post #74

Good news is that for DDR5, ECC is a required part of the spec and should be a feature of every module: https://www.anandtech.com/show/15912/ddr5-specification-rele...

I read it to say that on die ecc is recommended but that dimm-wide ecc is still optional.

And now you have 8 bits of ecc per 32 data versus older DDR having 8 bits of ecc per 64 data. Hence the cost for dimm-wide ecc is going up.

Re: ECC matters

#109

Post by [deleted] »

raverbashing wrote: post #23
simias wrote: post #13

Earlier quoted context omitted.

For a 2nd language speaker making these homophonic mistakes is actually a sign of fluency. It means that you just transcribe a mental flow of words instead of consciously constructing the language. The first time I wrote "your" instead of "you're" in English I thought it was quite a milestone!

> For a 2nd language speaker making these homophonic mistakes is actually a sign of fluency. I kinda disagree because while the homophony works in (spoken) English in written it stands as a sore thumb. So yeah you will make it if you only heard it but doesn't know the written form. (And in their native language it's probably two unrelated words, so that might intensify the feeling of wrongness)

[deleted]

Re: ECC matters

#110

Post by alkonaut »

louwrentius wrote: post #44

ECC matters, even on the desktop, it's not even a discussion, to me. If you think it doesn't matter: how do you know? If you don't run with ECC memory, you'll never know if memory was corrupted (and recovered). That blue screen, that sudden reboot, that program crashing. That corrupted picture of your kid. Who knows. I'll tell you, who knows. God damn every sysadmin (or the modern equivalent) can tell you how often t…

I know what it does, but I still don’t care (so long as it costs money or even 1% performance).

It’s a tradeoff between money/performance and the frequency of crashes, corruption etc.

Bit rot is just one of many threats to my data. Backups take care of that as well as other threats like theft, fire, accidental deletion.

This is similar to my reasoning around the recent side channel attacks on intel CPUs. If I had a choice I’d like to run with max performance without the security fixes even though it would be less secure. Not because I don’t care about security but because 1% or 5% perf is a lot and I’d rather simply avoid doing anything security critical on the machine entirely than take that hit.

Post reply on HN