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

171–180 of 567 posts

Re: ECC matters

#171

Post by cturner »

cuu508 wrote: post #100
vvanders wrote: post #83

Earlier quoted context omitted.

I don't think Threadripper is a hard requirement for ECC. There's some pretty reasonable TDP processors if you step down from Threadripper.

I haven't seen definite details and test results on these (but haven't looked recently). What specific configurations (CPU, MB, RAM) are known to work? Let's say I have a Ryzen system, how can I check if ECC really works? Like, can I see how many bit flips got corrected in, say, last 24h?

Regarding verification. There is a debian package called edac-utils. As I recall you overclock your RAM and run your system at load in order to generate failures.

Looking back at my notes, the output of journalctl -b tells should say something like, "Node 0: DRAM ECC enabled."

Then 'edac-ctl --status' should tell you that drivers are loaded.

Then you run 'edac-util -v' to report on what it has seen,

    mc0: 0 Uncorrected Errors with no DIMM info
    mc0: 0 Corrected Errors with no DIMM info
    mc0: csrow2: 0 Uncorrected Errors
    mc0: csrow2: mc#0csrow#2channel#0: 0 Corrected Errors
    mc0: csrow2: mc#0csrow#2channel#1: 0 Corrected Errors
    mc0: csrow3: 0 Uncorrected Errors
    mc0: csrow3: mc#0csrow#3channel#0: 0 Corrected Errors
    mc0: csrow3: mc#0csrow#3channel#1: 0 Corrected Errors
    edac-util: No errors to report.

Re: ECC matters

#172

Post by Tade0 »

xxs wrote: post #126
jacquesm wrote: post #107

Earlier quoted context omitted.

How is your Finnish?

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 guess this is what happens when someone first learns to speak the language, learning how to write in it only later on - as it often is the case with children.

I spent my preschool years in a multicultural environment and English was our lingua franca(ironically the school-mandated language was French), so I didn't properly learn contractions until grade school - same with similarly sounding words like "than vs then" and "your vs you're".

Re: ECC matters

#173

Post by bayindirh »

411111111111111 wrote: post #159
bayindirh wrote: post #151

Earlier quoted context omitted.

> I've never seen anyone shop a desktop CPU by TDP, rather than by performance and price. That's me. When I start to plan for a new system, I select the processor first and read its thermal design guidelines (Intel used to have nice load vs. max temp graphs in their docs) and select every component around it for sustained max load. This results in a more silent system for idle and peace of mind for loading it for ext…

That's not necessarily correct. You can passively cool threadrippers if you underclock them enough and have good ventilation in case.

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.

Re: ECC matters

#174

Post by p_l »

cuu508 wrote: post #100
vvanders wrote: post #83

Earlier quoted context omitted.

I don't think Threadripper is a hard requirement for ECC. There's some pretty reasonable TDP processors if you step down from Threadripper.

I haven't seen definite details and test results on these (but haven't looked recently). What specific configurations (CPU, MB, RAM) are known to work? Let's say I have a Ryzen system, how can I check if ECC really works? Like, can I see how many bit flips got corrected in, say, last 24h?

All AMD CPUs with integrated memory controllers support ECC. The CPU also exposes an interface usable by the operating system to verify ECC works - the same interface is used to provide monitoring of memory fault data provided by ECC.

They aren't tested on it, so it's possible to get a dud, but it's minuscule chance that isn't worth bothering.

Now, to actual issues you can encounter: motherboards

The problem is that ECC means you need to have, iirc, 8 more data lines between CPU and memory module, which of course mean more physical connections (don't remember how many right now). Those also need to be properly done and tested, and you might encounter a motherboard where it wasn't done. Not sure how common, unfortunately.

Another issue is motherboard firmware. Even though AMD supplies the memory init code, the configuration can be tweaked by motherboard vendor, and they might simply break ECC support accidentally (even by something as simple as making a toggle default to false then forgot to expose it in configuration menu).

Those are the two issues you can encounter.

The difference with AFAIK Threadripper PRO, and EPYC, is that AMD includes ECC in its test and certification programs for it, which kind of enforces support.

Re: ECC matters

#175

Post by wmf »

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.

Historically the detection and correction is performed in the memory controller not the DRAM.

Re: ECC matters

#176

Post by p_l »

CoolGuySteve wrote: post #140
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 always wondered why isn't ECC built into the memory controller, the same hardware that runs the bus into L3 or the page mapper could checksum groups of cachelines. It seems redundant to have every module come with its own checking hardware.

ECC is a function of memory controller, not memory, on current systems. There's also usually some form of ECC on whatever passes for system bus, and internal caches have ECC as well.

For memory controller, parity/ECC/chipkill/RAIM usually involved simply adding additional memory planes to store correction data. I believe the rare exceptions are fully buffered memories where you have effectively separate memory controller on each module (or add-in card with DIMMs)

Re: ECC matters

#177

Post by stefan_ »

defanor wrote: post #66
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…

I've considered using an AMD CPU instead of Intel's Xeon on the primary desktop computer, but even low-end Ryzen Threadripper CPUs have TDP of 180W, which is a bit higher than I'd like. And though ECC is not disabled in Ryzen CPUs, AFAIK it's not tested in (or advertised for) those, so one won't be able to return/replace a CPU if it doesn't work with ECC memory, AIUI, making it risky. Though I don't know how common i…

I don't understand. Whatever the TDP of Intel processors, you are straight up getting less bang for watt given their ancient process. Same reason smartphones burst to high clocks and power; getting the task done faster is on average much more efficient.

Re: ECC matters

#178

Post by tyoma »

zx2c4 wrote: post #68
paulie_a wrote: post #41

There was a great defcon talk a while back regarding using ECC. The concept was called "dns jitter" Basically you can register domains using small bit differences for domains and start getting email and such for that domain If I recall correctly the example given was a variation of microsoft.com All because so much equipment doesn't use ECC

Voila http://media.blackhat.com/bh-us-11/Dinaburg/BH_US_11_Dinabur...

There were some great follow up talks as well! It turns out a viable attack vector was also MX records. And there was the guy who registered kremlin.re ( versus kremlin.ru ).

Re: ECC matters

#179

Post by p_l »

spacedcowboy wrote: post #47

Seems likely that “bad ram” was the reason for the recent AT&T fiber issues, given that 1 bit was being flipped reliably in data packets [1] [1]: https://twitter.com/catfish_man/status/1335373029245775872?l...

I have had in the past encountered an issue where line card was stripping exactly one bit of address data. Don't know of the follow up investigation, but it probably wasn't TCAM

Re: ECC matters

#180

Post by lolc »

harperlee wrote: post #132
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!

As an “english as a second language” user, I can’t see myself writing e.g. “should of” instead of “should have”, however fluent I am. I think you don’t make that kind of typo unless you have learnt english before grammar.

I was quite surprised when it started happening to me.
Post reply on HN