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

151–160 of 567 posts

Re: ECC matters

#151

Post by bayindirh »

CydeWeys wrote: post #78
defanor wrote: post #66

Earlier quoted context omitted.

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…

> but even low-end Ryzen Threadripper CPUs have TDP of 180W, which is a bit higher than I'd like. Why does it matter? It doesn't idle that high; it only goes that high of you're using it flat out, in which case the extra power usage is justified because it's giving that much more performance over a 100 W TDP CPU. Now I totally get it if you don't want to go Threadripper just for ECC because it's more expensive , but…

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

Re: ECC matters

#152

Post by cbanek »

jackric wrote: post #101
faitswulff wrote: post #95

Earlier quoted context omitted.

Do the crash reports include whether the machine has ECC memory?

Do the crash reports include recent solar activity?

Well, I've had to actually worry about radiation bitflips as well. It does happen. But usually not so much on Earth!

Re: ECC matters

#153

Post by cturner »

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 went through this about a year ago, to build a low-TDP ECC workstation. I do not have stats on failure rates, just this anecdotal experience. Asrock and Asus seem to be the boards to get. For RAM, I got two sticks of Samsung M391A4G43MB1, and verified. The advice I remember from the forums was to stick to unbuffered ram (UDIMMS).

Re: ECC matters

#154

Post by vlovich123 »

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

Re: ECC matters

#155

Post by slim »

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

Re: ECC matters

#156

Post by kasabali »

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.

AFAIK it is built into the memory controller, at least for ECC UDIMM. There's an extra DRAM chip on the module for parity (generally 8+1), but it is memory controllers responsibility to utilize it (that's why not all CPUs support ECC)

Re: ECC matters

#157

Post by washadjeffmad »

freeqaz wrote: post #10

I bought ECC RAM for my laptop and it definitely was about 4x the price. It's valuable to me for a few reasons -- peace of mind being a big one. Bit flips happen and are real. I really wish ECC was plentiful and not brutally expensive!

For the price, it made more sense for me to buy an R630 and populate it with a few less expensive, higher capacity ECC RDIMMs. I don't really need ECC as a local feature, so this lets me run on the mobile I want.

Re: ECC matters

#158

Post by bitcharmer »

mrlala wrote: post #124
bitcharmer wrote: post #28

Earlier quoted context omitted.

A system on Earth, at sea level, with 4 GB of RAM has a 96% percent chance of having a bit error in three days without ECC RAM. With ECC RAM, that goes down to 1.67e-10 or about one chance in six billions. So I'd say ECC is not only important but insanely impactful. There's a reason why many organizations don't even want to hear about getting rigs with non-ECC memory.

So, I hear what you are saying. But, on the other hand, I have been using 2 non-ECC desktops for a workstation/server for the past ~6 years.. and I would be hard pressed to come up with a single situation where either of the machines randomly crashed or applications did anything 'unexpected' (to my knowledge, of course). My point is, when you say there is a "96% chance of having an error in THREE DAYS", one would EXP…

Your questions are perfectly valid. It's just that out of all the random bit flips that happen over a period of time on a non-ECC platform only a miniscule percentage will manifest to you in any noticeable way.

Most will escape your attention.

Re: ECC matters

#159

Post by 411111111111111 »

bayindirh wrote: post #151
CydeWeys wrote: post #78

Earlier quoted context omitted.

> but even low-end Ryzen Threadripper CPUs have TDP of 180W, which is a bit higher than I'd like. Why does it matter? It doesn't idle that high; it only goes that high of you're using it flat out, in which case the extra power usage is justified because it's giving that much more performance over a 100 W TDP CPU. Now I totally get it if you don't want to go Threadripper just for ECC because it's more expensive , but…

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

Re: ECC matters

#160

Post by KingMachiavelli »

MaxBarraclough wrote: post #75
dijit wrote: post #25

Earlier quoted context omitted.

There are situations though, where you’re working on a document and the documents “save” format is a memory dump. Corruption for things of that type (Adobe RAW for example) would remove data. It might present itself as a 1pixel colour difference, but it could be more damaging (incorrect finances, in accounting software for example). Software trusts memory; but memory can lie. That’s dangerous.

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.
Post reply on HN