ECC matters • Hacker News Board

Re: ECC matters

#241

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

ReactiveJelly wrote: post #223

mlyle wrote: post #182

Earlier quoted context omitted.

On AMD, with Ryzen Master, you can set the TDP-envelope of the processor to what you want. Then the boost/frequency/voltage envelope it chooses to operate in under sustained load is different. IMO, shopping by performance/watt makes sense. Shopping by TDP doesn't. (Especially since there is no comparing the AMD and Intel TDP numbers as they're defined differently; neither is the maximum the processor can draw, and In…

Back when my daily driver was a Core 2 laptop, someone told me that capping the clock frequency would make it unusable. As a petty "Take that", I dropped the max frequency from 2.0 GHz to 1.0 GHz. I ran a couple benchmarks to prove the cap was working, and then just kept it at 1.0 for a few months, to prove my point. It made a bigger difference on my ARM SBC, where I tried capping the 1,000 MHz chip to 200 or 400 MHz…

The funny thing is, on modern processors-- throttling TDP only affects when running flat out all-core workloads. A subset of cores can still boost aggressively, and you can run all-core max-boost for short intervals.

And the relationship between power and performance isn't linear as processor voltages climb trying to squeeze out the last bit of performance.

So if you want to take a 105W CPU and ask it to operate in a 65W envelope, you're not giving up even 1/3rd of peak performance, and much less than that of typical performance.

Re: ECC matters

#242

Post by ikiris » Sun, Jan 03, 2021, 6:32 PM UTC

hosteur wrote: post #144

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…

How did you track memory errors across thousands of physical machines?

The same way you do it with everything else, export the telemetry and store it in time series...

Re: ECC matters

#243

Post by Glanford » Sun, Jan 03, 2021, 6:32 PM UTC

mark-r wrote: post #196

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

I have a simple way of remembering when to leave out the apostrophe. His, hers, its are all possessive and none of them have an apostrophe.

In this particular case 'it's' can also be possessive although it's considered non-standard, so to be correct you can always treat it like a contraction of 'it is'.

Re: ECC matters

#244

Post by tomxor » Sun, Jan 03, 2021, 6:32 PM UTC

bitcharmer wrote: post #165

tomxor wrote: post #36

Earlier quoted context omitted.

I like when people back up their claims with numbers, but would you mind describing roughly what that 96% probability of error is based upon? I understand altitude has some kind of proportionality to cosmic ray exposure, and number of bits will multiply the probability of an error.. I'm presuming there is also an inherent error rate to DRAM separate from environment. But what are those numbers.

Apologies, you're totally right. I should have linked to the source: http://lambda-diode.com/opinion/ecc-memory#:~:text=A%20syste... .

Great thanks!

[edit]

Looks like the calculation was revised [0] after criticism:

> Under these assumptions, you'll have to wait about 33 to 600 days to get a 96% chance of getting a bit error.

What's more worrying is the variance, the above calculation is based on expected well behaved DRAM.. yet some computers just seem to have manufacturing defects that make the incidence of errors high enough to be a regular problem.

[0] http://lambda-diode.com/opinion/ecc-memory-2

Re: ECC matters

#245

Post by wicket » Sun, Jan 03, 2021, 6:34 PM UTC

Over the years, I don't think I've ever been able to explain to anyone that their memory error could have been caused a cosmic ray without being laughed at.

Re: ECC matters

#246

Post by ikiris » Sun, Jan 03, 2021, 6:35 PM UTC

incrudible wrote: post #149

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…

When you say bitflips were "common" on thousands of physical machines, does that mean you observed thousands of bitflips? Otherwise, I would think that an unlikely event becoming 1000x more likely by sheer numbers would have warped your perception. I believe that hardware reliability is mostly irrelevant, because software reliability is already far worse. It doesn't matter whether a bitflip (unlikely) or some bug (li…

Its enough that graphs can show you solar weather.

I can't give my source, but its far higher than most people think. Just pay the money.

Re: ECC matters

#247

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

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…

> one won't be able to return/replace a CPU if it doesn't work with ECC memory

I don't know where you live, but around here, (if you buy new?), the vendor MUST take back items up to 15 days after they were delivered, for ANY reason.

So, as long as you synchronize your buying of CPU, RAM, (motherboard), you should be fine.

Re: ECC matters

#248

Post by temac » Sun, Jan 03, 2021, 6:37 PM UTC

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…

The RAM already needs to be refreshed and IIRC it is done by the memory controller when not in sleep mode.

However I don't remember if there are provisions for ECC checking in case there are some dedicated refresh commands. I hope so, but I'm not sure.

Re: ECC matters

#249

Post by harperlee » Sun, Jan 03, 2021, 6:37 PM UTC

lolc wrote: post #180

harperlee wrote: post #132

Earlier quoted context omitted.

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.

Wow that’s interesting!

Re: ECC matters

#250

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

ethanpil wrote: post #236

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…

Built a NAS. My #1 concern for choosing CPU was TDP. This machine is on 24/7 and power use is a primary concern where I live because electricity is NOT cheap.

This is a poor way to make the choice. TDP is supposed to specify the highest power you can get the processor to dissipate, not typical or idle use. And since different manufacturers specify TDP differently, you can't even compare the number.

Performance/watt metrics and idle consumption would have been a far better way to make this choice.

If you have a choice between A) something that can dissipate 65W peak for 100 units of performance, but would dissipate 4W average under your workload, and B) something that can dissipate 45W peak for 60 units of performance, but would dissipate 4.5W under your workload... I'm not sure why you'd ever pick B.