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

211–220 of 567 posts

Re: ECC matters

#211

Post by loeg »

fortran77 wrote: post #141
loeg wrote: post #33

Earlier quoted context omitted.

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…

While it's true that Intel only has ECC support on Xeon (and several other chips targeted at the embedded market) it's not true that ECC is supported well on AMD. We only use Xeons on developer desktops and production machines here precisely because of ECC. It's about 1 bit flip/month/gigabyte. That's too much risk when doing something critical for a client.

> it's not true that ECC is supported well on AMD.

That's an extreme claim. Why do you say so?

Re: ECC matters

#212

Post by bayindirh »

mlyle wrote: post #190
bayindirh wrote: post #173

Earlier quoted context omitted.

If my only interest would be ECC, I might do that but, I develop scientific software for research purposes. I need every bit of performance from my system. In my case loading means maxing out all cores and extended period of time can be anything from five minutes to hours.

The problem is-- you can't compare the TDP nor even the system cooling design guidelines between AMD and Intel. Both are optimistic lies, but-- if you look at the documents it looks like currently AMD needs more cooling, but actually dissipates less power in most cases and definitely has higher performance/watt.

> The problem is-- you can't compare the TDP nor even the system cooling design guidelines between AMD and Intel.

Doesn't matter for me since I'm not interested in comparing them.

> Both are optimistic lies, but-- if you look at the documents it looks like currently AMD needs more cooling, but actually dissipates less power in most cases and definitely has higher performance/watt.

I'm aware of the situation, and I always inflate the numbers 10-15% to increase headroom in my systems. The code I'm running is not a most case code. A FPU heavy, "I will abuse all your cores and memory bandwidth" type, heavily optimized scientific software. I can sometimes hear that my system is swearing at me for repeatedly running for tests.

I don't like to add this paragraph but, I'm one of the administrators of one of the biggest HPC clusters in my country. I know how a system can surpass its TDP or how can CPU manufacturers skew this TDP numbers to fit in envelopes. We make these servers blow flames from their exhausts.

Re: ECC matters

#213

Post by mark-r »

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…

Backups can't fix what was already corrupted when it was written to disk.

Re: ECC matters

#214

Post by jeffbee »

jacquesm wrote: post #113
JoeAltmaier wrote: post #92

ECC works if done right. Accessing a memory location can fix bit-flips (ECC is a 'correcting' code). But systems that don't regularly visit every memory location, can accumulate risk. Those dark corners of RAM can eventually get double-bit errors and be uncorrectable. So an OS might 'wash' RAM during idle moments, reading every location in a round-robin manner to get ECC to kick in and auto-correct. Doesn't matter ho…

Interesting, similar to scrubbing raid arrays. How often do those double bitflips appear though? You'd have to have a pretty long running server for that to be a problem, no?

According to Google's old paper on the subject, about 1% of their machines suffered from an uncorrectable (i.e. multi-bit) error in a year.

Re: ECC matters

#215

Post by mlyle »

francis-io wrote: post #169
sam_lowry_ wrote: post #131

Earlier quoted context omitted.

Hm... My 2013 NUC in fanless Akasa enclosure runs 24/7 on a 6W CPU, I recently looked at the options, and the 2019 6W offering changes little in performance. Yes, memory got faster, but that's it. My passive-cooled desktop is also running a slightly trottled down 65W CPU. So yes, there are people who choose there hardware by TDP.

When looking for a CPU for a server that sits in my living room, I went down the thought process of getting a low tdp. I don't have a quote, but I seem to remember coming to the conclusion that tdp is the max temp threshold, not the consistent power draw. If you have a computer idling I believe you won't see a difference in temp between cpus, but you will have the performance when you need it. These days, a quiet, pw…

Yah-- one should look at performance within a given power envelope. Being able to dissipate more and then either end up with the fan running or the processor throttling back somewhat is good, IMO.

The worst bit is, AMD and Intel define TDP differently-- neither is the maximum power the processor can draw-- though Intel is far more optimistic.

Re: ECC matters

#216

Post by loup-vaillant »

slim wrote: post #155
otterley wrote: post #82

D. J. Bernstein (of qmail/daemontools fame) spoke of it over a decade ago as well. https://cr.yp.to/hardware/ecc.html

these days he's more famous for the NaCl crypto library

For which bit flips are even more relevant: EdDSA has this nasty tendency of leaking the private key if the wrong bits are flipped (there are papers on fault injection attacks). People who sign lots of stuff all the time, say Let's Encrypt, could conceivably gain some piece of mind with ECC.

(Note: EdDSA is still much much better than ECDSA, most notably because it's easier to implement correctly.)

Re: ECC matters

#217

Post by theevilsharpie »

fortran77 wrote: post #141
loeg wrote: post #33

Earlier quoted context omitted.

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…

While it's true that Intel only has ECC support on Xeon (and several other chips targeted at the embedded market) it's not true that ECC is supported well on AMD. We only use Xeons on developer desktops and production machines here precisely because of ECC. It's about 1 bit flip/month/gigabyte. That's too much risk when doing something critical for a client.

> it's not true that ECC is supported well on AMD

ECC is supported on most Ryzen models[1], as long as the motherboard supports it. In fact, ASUS and ASRock (possibly others) have Ryzen motherboards designed for workstation/server use where ECC support is specifically advertised.

[1] The only exception is the Ryzen CPUs with integrated graphics.

Re: ECC matters

#218

Post by mark-r »

KingMachiavelli wrote: post #160
MaxBarraclough wrote: post #75

Earlier quoted context omitted.

That's an interesting point. In an extreme case, an order or money transfer might be placed for an incorrect quantity, or to an incorrect recipient.

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's the principle behind Gray Code counting: https://en.wikipedia.org/wiki/Gray_code

Re: ECC matters

#220

Post by pkaye »

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…

I wonder how much of those crashes are due to gamers aggressively overclocking their systems?
Post reply on HN