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

301–310 of 567 posts

Re: ECC matters

#301

Post by rajesh-s »

theevilsharpie wrote: post #230
vlovich123 wrote: post #154

A couple of years ago there was advancements that claimed to make Rowhammer work on ECC RAM even with DDR4 [1]. Is that no longer a concern for some reason? I would think the only guaranteed solutions to Rowhammer are actually cryptographic digests and/or guard pages. [1] https://www.zdnet.com/article/rowhammer-attacks-can-now-bypa...

ECC isn't a direct mitigation against Rowhammer attacks, as memory errors caused by three or more flipped bits would still go undetected (unless you're using ChipKill, but that's a rare setup). However, flipped three bits simultaneously isn't trivial, and the attempts that flip fewer bits will be detected and logged.

Right! Section 1.3 of this publication discusses possible mitigations for the row hammer problem and where ECC fits in

https://users.ece.cmu.edu/~omutlu/pub/rowhammer-summary.pdf

Re: ECC matters

#302

Post by mlyle »

Cloudef wrote: post #296
mlyle wrote: post #271

Earlier quoted context omitted.

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

Ryzen Master doesnt seem to be available for linux so you end up with bunch of unnofficial hacks that may or may not work. I run sff setup myself, originally wanted to get 3600 but it was out of stock, and the next tdp friendly processor was 3700x.

That's an annoyance, but on Linux you have infinite more control of thermal throttling and you can get whatever thermal behavior you want. Thermald has been really good on Intel, and now that Google contributed RAPL support you can get the same benefits on AMD-- pick exactly your power envelope and thermal limits.

Re: ECC matters

#303

Post by GregarianChild »

theevilsharpie wrote: post #230
vlovich123 wrote: post #154

A couple of years ago there was advancements that claimed to make Rowhammer work on ECC RAM even with DDR4 [1]. Is that no longer a concern for some reason? I would think the only guaranteed solutions to Rowhammer are actually cryptographic digests and/or guard pages. [1] https://www.zdnet.com/article/rowhammer-attacks-can-now-bypa...

ECC isn't a direct mitigation against Rowhammer attacks, as memory errors caused by three or more flipped bits would still go undetected (unless you're using ChipKill, but that's a rare setup). However, flipped three bits simultaneously isn't trivial, and the attempts that flip fewer bits will be detected and logged.

Isn't ChipKill just another form of ECC? If so there is a number of bitflips that ChipKill can no longer correct / detect. [1] seems to say that they observed some flips in dRAM with ChipKill, although the paper is a bit vague here.

[1] B. Schroeder et al, DRAM Errors in the Wild: A Large-Scale Field Study http://www.cs.toronto.edu/~bianca/papers/sigmetrics09.pdf

Re: ECC matters

#304

Post by GregarianChild »

rajesh-s wrote: post #301
theevilsharpie wrote: post #230

Earlier quoted context omitted.

ECC isn't a direct mitigation against Rowhammer attacks, as memory errors caused by three or more flipped bits would still go undetected (unless you're using ChipKill, but that's a rare setup). However, flipped three bits simultaneously isn't trivial, and the attempts that flip fewer bits will be detected and logged.

Right! Section 1.3 of this publication discusses possible mitigations for the row hammer problem and where ECC fits in https://users.ece.cmu.edu/~omutlu/pub/rowhammer-summary.pdf

The paper you cite is from 2014 and the mitigations discussed there have all been circumvented. [1] is from 2020 and a better read for Rowhammer mitigation.

[1] J. S. Kim et al, Revisiting RowHammer: An Experimental Analysis of Modern DRAM Devices and Mitigation Techniques https://arxiv.org/abs/2005.13121

Re: ECC matters

#306

Post by adrian_b »

js2 wrote: post #234
theevilsharpie wrote: post #217

Earlier quoted context omitted.

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

Depends what you mean by supported. Semi-offically: ECC is not disabled. It works, but not validated for our consumer client platform. Validated means run it through server/workstation grade testing. For the first Ryzen processors, focused on the prosumer / gaming market, this feature is enabled and working but not validated by AMD. You should not have issues creating a whitebox homelab or NAS with ECC memory enabled…

Yes there is a risk to buy a Ryzen CPU with non-functional ECC.

However, I use only computers with ECC, previously only Xeons, but in the last years I have replaced many of them with Ryzens, all of which work OK with ECC memory.

When having to choose between a very small risk of losing the price of a CPU and having to use for sure, during many years, an Intel CPU with half of the AMD speed, the choice was very obvious for me.

Re: ECC matters

#307

Post by mlyle »

mongol wrote: post #292
mlyle wrote: post #250

Earlier quoted context omitted.

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…

Is there a metric to look for to understand what power consumption is at "idle" or something close to that? That is what confuses me. I don't want to spend a lot of money on something that will be always on, and usually idling, and finding that its power usage is way higher than I thought. But perhaps there is a metric that tells that. I have not looked closely at it. Also, even though the CPU may draw less, can stil…

> Is there a metric to look for to understand what power consumption is at "idle" or something close to that? That is what confuses me. I don't want to spend a lot of money on something that will be always on, and usually idling, and finding that its power usage is way higher than I thought.

Community benchmarks, from Tom's Hardware, etc.

The vendor numbers are make believe-- you can't use them for power supply sizing or for thermal path sizing. If you look at the cited TDP numbers today-- it can be misleading-- e.g. often Intel 45W TDP parts use more power at peak than AMD 65W parts.

On modern systems, almost none of the idle consumption is the processor. The power supply's idle use and motherboard functions dominate.

> Also, even though the CPU may draw less, can still the power supply waste more, just because it is beefy?

Yes, having to select a larger power supply can result in more idle consumption, though this is more of a problem on the very low end.

Re: ECC matters

#308

Post by layer8 »

MAXPOOL wrote: post #221

Well shit. I run some large ML models in my home PC and I get NaN's and some out of range floats every month or so. I have spent hours debugging but doing the same computation with the same random seeds does not recreate the problem. How about GPU's and their GDDR SDRAM? Do they have parity bits?

Some pro-level Nvidia GPUs have ECC RAM, they are very expensive though. I don’t think regular gaming GPUs have parity, due to the extra cost, performance impact (probably minor but measurable) and irrelevance for gaming.

Re: ECC matters

#309

Post by ajnin »

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…

> I've got nearly 30 years of experience and not once has non ECC memory lead to corruption

How do you know?

Re: ECC matters

#310

Post by skibbityboop »

knorker wrote: post #232

I have multiple times postponed buying new computers for YEARS, because I'm waiting for intel to get their head out of their ass and actually let me buy something that does ECC for desktop. (incl laptops) I would have bought computers when I "wanted one". Now I buy them when I need one. Because buying a non-ECC computer just feels like buying a defective product. In the last 10 years I would have bought TWICE as many…

Have you finally stopped buying Intel? Current Ryzens are a much better CPU anyhow, just dump Intel and be happy with your ECC and everything else.
Post reply on HN