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

191–200 of 567 posts

Re: ECC matters

#191

Post by tyoma »

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…

It depends where the failure happens. Sometimes you really lose the “failure in the wrong place” lottery. For example, in a domain name: http://dinaburg.org/bitsquatting.html

Re: ECC matters

#192

Post by mlyle »

marcosdumay wrote: post #72
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…

Keep in mind that Intel lies about its TDP.

They both lie, but Intel lies worse :D

Re: ECC matters

#193

Post by jjeaff »

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…

Ya, I'm not buying that biyflips are a problem. Or maybe modern software can correct better for this? Because I use my desktop all day everyday running tons of software on 64 gb of ram and I don't get errors or crashes often enough to remember ever having one.

Re: ECC matters

#194

Post by MarkusWandel »

This is one justified Linus rant! My personal history includes data loss twice because of defective RAM, and many more RAMs discarded after the now obligatory overnight run of MemTest86+ (these were all secondhand RAMs - I would never buy a new one without a refund guarantee). My very first "PC" still had the ECC capability and I used it. My own now very dated rant on the subject: http://wandel.ca/homepage/memory_rant.html

Re: ECC matters

#195

Post by markonen »

dijit wrote: post #58
bitcharmer wrote: post #34

Earlier quoted context omitted.

This is the first time I hear about a laptop that supports ECC memory. Could you please share the make and model?

I have a Dell Precision 5520 (chassis of an XPS 15) which has a Xeon and ECC memory. Finding a memory upgrade seems difficult though.

I was looking at getting the Xeon-based NUC recently and one of the reasons I decided against it was that ECC SO-DIMMs seem to be a really marginal product. If you want ECC, something that takes full-size DIMMs seems much easier to buy memory for.

Re: ECC matters

#196

Post by mark-r »

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.

Re: ECC matters

#197

Post by hollerith »

minot wrote: post #51
rhn_mk1 wrote: post #38

Earlier quoted context omitted.

Doesn't intel make ECC available on the i3 line of CPUs?

I was going to say no but I just checked and at least ONE latest generation i3 processor supports ECC https://ark.intel.com/content/www/us/en/ark/compare.html?pro... https://ark.intel.com/content/www/us/en/ark/products/208074/... Problem is this processor is an Embedded processor so probably not for us > Industrial Extended Temp, Embedded Broad Market Extended Temp My understanding is Intel does not support ECC on th…

That i3 is for file servers.

Re: ECC matters

#198

Post by vvanders »

mlyle wrote: post #182
phkahler wrote: post #117

Earlier quoted context omitted.

>> I've never seen anyone shop a desktop CPU by TDP, rather than by performance and price. Oh oh, me! Back in the day I bought a 65W CPU for a system that could handle a 90W. I wanted quiet and figured that would keep fan noise down at a modest performance penalty. It should also last longer, being the same design but running cooler. I ran that from 2005 until a few years ago (it still run fine but is in storage). Pl…

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…

TDP matters a fair bit in SFF(Small Form Factor) PCs. For instance the 3700x is a fantastic little CPU since it has a 65W TDP but pretty solid performance.

In a sandwich style case you're usually limited to low profile coolers like Noctua L9i/L9a since vertical height is pretty limited.

Re: ECC matters

#200

Post by mlyle »

cududa wrote: post #145
toast0 wrote: post #118

Earlier quoted context omitted.

On die ECC is great for increasing reliability, if all else is equal, but if it doesn't report to the memory controller, and if the memory controller doesn't report to the OS, I think it will be worse than status quo, because all else won't be equal. With no feedback, systems are going to continue to run on the edge, but now detectable failures will all be multi-bit; because single bit errors are hidden.

Huh? Why would the memory controller not be updated accordingly? Also I have no idea about Linux or Mac, but Windows has had ECC support and active management for decades?

Normally, ECC has meant just the DIMM stores some extra bits, and the memory controller itself implements ECC-- writing the extra parity, and recovering when errors emerge (and halting when non-recoverable errors happen).

DDR5 includes on-die ECC, where the RAM fixes the errors before sending them over the memory bus.

This means if the bus between the processor and ram corrupts the bits-- tough luck, they're still corrupted. And it's unclear whether we're going to get the quality of memory error reporting that we're used to or get the desired halt-on-non-recoverable error behavior (I've not been able to obtain/read the DDR5 specification as yet).

Post reply on HN