ECC matters • Hacker News Board

Re: ECC matters

#271

Post by mlyle » Sun, Jan 03, 2021, 6:55 PM UTC

mongol wrote: post #255

mlyle wrote: post #209

Earlier quoted context omitted.

Performance/watt matters. You can just set TDP to what you want with throttling choices. If you want a 45W TDP from the 3700X, you can just pop into Ryzen Master and ask for a 45W TDP. Boom, you're running in that envelope. I think shopping based on TDP is not the best, because it's not comparable between manufacturers and because it's something you can effectively "choose".

How do you do that? Is it a setting in the bios? Or can it be done runtime? If so, how? It sounds interesting if I can run a beefy rig as a power efficient device, for always-on scenarios, and then boost it when I need.

> How do you do that? Is it a setting in the bios? Or can it be done runtime?

On AMD, it's a utility you run. I believe you may require a reboot to apply it. On some Intel platforms, it's been settings in the BIOS.

> It sounds interesting if I can run a beefy rig as a power efficient device, for always-on scenarios, and then boost it when I need.

This is what the processor is doing internally anyways. It throttles voltage and frequency and gates cores based on demanded usage. Changing the TDP doesn't change the performance under a light-to-moderate workload scenario at all.

Ryzen Master lets you change some of the tuning for the choices it makes about when and how aggressively to boost, though, too.

Re: ECC matters

#272

Post by dehrmann » Sun, Jan 03, 2021, 6:56 PM UTC

jacquesm wrote: post #226

jankeymeulen wrote: post #119

Earlier quoted context omitted.

Or Swedish for that matter, as I believe Torvalds maternal language is Swedish

Finnish is stupendously hard. Far harder than Swedish, at least, by my estimation.

It is. Swedish and English are both Germanic languages, so there are a lot of commonalities. Finnish is in a completely different language family. English and Swedish are more closely related to Persian and Hindi than to Finnish.

Re: ECC matters

#273

Post by BlueTemplar » Sun, Jan 03, 2021, 6:57 PM UTC

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…

Yeah, here's one example along many more :

https://forums.factorio.com/viewtopic.php?p=405060#p405060

Re: ECC matters

#274

Post by maria_weber23 » Sun, Jan 03, 2021, 7:01 PM UTC

nostrademons wrote: post #237

I still remember Craig Silverstein being asked what his biggest mistake at Google was and him answering "Not pushing for ECC memory." Google's initial strategy (c. 2000) around this was to save a few bucks on hardware, get non-ECC memory, and then compensate for it in software. It turns out this is a terrible idea, because if you can't count on memory being robust against cosmic rays, you also can't count on the soft…

ECC memory can't eliminate the chances of these failures entirely. They can still happen. Making software resilient against bitflips in memory seems very difficult though, since it not only affects data, but also code. So in theory the behavior of software under random bit flips is well... Random. You probably would have to use multiple computers doing the same calculation and then take the answer from the quorum. I could imagine that doing so would still be cheaper than using ECC ram, at least around 2000.

Generally this goes against software engineering principles. You don't try to eliminate the chances of failure and hope for the best. You need to create these failures constantly (within reasonable bounds) and make sure your software is able to handle them. Using ECC ram is the opposite. You just make it so unlikely to happen, that you will generally not encounter these errors at scale anymore, but nontheless they can still happen and now you will be completely unprepared to deal with them, since you chose to ignore this class of errors and move it under the rug.

Another intersting side effect of quorum is that it also makes certain attacks more difficult to pull off, since now you have to make sure that a quorum of machines gives the same "wrong" answer for an attack to work.

Re: ECC matters

#275

Post by louwrentius » Sun, Jan 03, 2021, 7:01 PM UTC

alkonaut wrote: post #110

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 c…

> 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.

No, that's the big mistake people make: backups just backup bit-rotted data, until it is too late and the last good version is rotated out and lost forever.

Re: ECC matters

#276

Post by dehrmann » Sun, Jan 03, 2021, 7:01 PM UTC

jacquesm wrote: post #225

xxs wrote: post #126

Earlier quoted context omitted.

Linus must have English as his '1st' language now. For non-originally-native speaker mistakes like 'it's vs its', 'than vs then', etc. are pretty uncommon.

I've spent my whole life speaking multiple languages and this still trips me up every now and then, in fact quotes as such are a problem for me and I keep using them wrong, no idea why, it just won't register. So unless I slow down to 1/10th of my normal writing speed I will definitely make mistakes like that. Good we have proofreaders :)

(guessing you mean apostrophes)

It's because they have two different uses (three if you count nested quotes, but those aren't common and are pretty easy to figure out), contractions and possession, and they seemingly collide on words like "its" where you'd think it could mean either.

Not sure if you've already learned this (or if it helps), but English used to be declined, and its pronouns still are, e.g. they/their/them. That's why "its" isn't contracted; the possessive marker is already in the word.

Re: ECC matters

#277

Post by jeffreygoesto » Sun, Jan 03, 2021, 7:02 PM UTC

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…

Sorry, I don't have the numbers you asked for. But afaik one other effect is that "modern" semiconductor processes like FinFET and Fully-Depleted Silicon-on-Insulator are less prone to single event upsets and especially result in only a single bit flipping and no drain of a whole region of transistors from a single alpha particle.

Re: ECC matters

#278

Post by [deleted] » Sun, Jan 03, 2021, 7:03 PM UTC

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...

[deleted]

Re: ECC matters

#279

Post by louwrentius » Sun, Jan 03, 2021, 7:04 PM UTC

supernovae wrote: post #79

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've got nearly 30 years of experience and not once has non ECC memory lead to corruption. Maybe a crash, maybe a panic, maybe a kernel dump... But.. in all my time operating servers over 3 decades, it's always been bad drivers, bad code and problematic hardware that's caused most of my headaches. Have i seen ECC error correction in logs? yeah.. I don't advocate against it but, i've found for most people you design a…

The problem with memory corruption is not just crashes, those are the more benign outcomes.

The real killer is data corruption. Houw would you even begin to know that data is corrupted until it is too late?

Re: ECC matters

#280

Post by rajesh-s » Sun, Jan 03, 2021, 7:04 PM UTC

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...

A whitepaper on DDR4 ECC by Micron that goes over some of the implementation challenges

https://media-www.micron.com/-/media/client/global/documents...