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

371–380 of 567 posts

Re: ECC matters

#371

Post by ksec »

Springcleaning wrote: post #323
cbanek wrote: post #77

As someone who has had to read thousands of random game crash reports from all over the interwebs (you know when Windows says you might want to send that crash log? like that), I totally agree. Of all the things to be worried about, like OS bugs, bad hardware configuration, etc. bad memory is one of those really troubling things. You look at the code and say "it's can't make it here, because this was set" but when yo…

Worse than a game crash is your data. It is incomprehensible that there are still NAS devices being sold without ECC support. Synology took a step in the right direction to offer prosumer devices with ECC but it is not really advertised as such. It is actually difficult to find which do have ECC and which ones don't.

>Synology took a step in the right direction to offer prosumer devices with ECC

I just look it up because if it was true it would have been news to me. Synology have been known to be stingy with Hardware Spec. But none of what I called Prosumer, the Plus Series have ECC memory by default. And there are "Value" and "J" Series below that.

Edit: Only two model from the new xx21 series using AMD Ryzen V has ECC memory by default.

Re: ECC matters

#372

Post by vbezhenar »

layer8 wrote: post #308
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.

Cheap pro-level GPUs don't have ECC RAM either. And it's not easy to find out, it might be buried somewhere.

Re: ECC matters

#373

Post by vbezhenar »

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…

There are plenty of Xeons which are suitable for desktops and there are plenty of laptops with Xeons.

Price is not nice though.

Re: ECC matters

#374

Post by a1369209993 »

KingMachiavelli wrote: post #170

Is there such a thing as 'software' ECC where a segment in memory also has a checksum stored in memory and the CPU just verifies it when the memory segment is accessed? It would be a lot slower than real ECC but it could just be used for operations that would be especially vulnerable to bit flips. It would also not know for certain if the memory segment of data or the memory segment holding the checksum was corrupted…

Actually... there is a word of memory that you already have to read every time you access a region of memory: the page table entry for that region. If you have 64-byte cache lines, that's 64 lines per (4KB) page, so you could load a second 64-bit word from the page table[0], and use that as a parity bit for each cache line, storing it back on write the same way you store active and dirty bits in the PTE proper. Actual E[correcting]C would require inflating the effective PTEs from 8(orginal)-16(parity) bytes to about 64(7 bits per line, insufficient)-128(15, excessive), which is probably untenable, but you could at least get parity checks this way.

There's also the obvious tactic of just storing every logical 64-bit word as 128 bits of physical memory, which gives you room for all kinds of crap[1], at the expense of halving your effective memory and memory bandwidth.

0: This is extremely cheap since you're loading a 64- vs 128-bit value, with no extra round trip time and still fits in a cache line, so you're likely just paying extra memory use from larger page tables.

1: Offhand, I think you could fit triple or even quadruple error correction into that kind of space (there's room for eight layers of SECDED, but I don't remember how well bit-level ECC scales).

Re: ECC matters

#375

Post by mixmastamyk »

dehrmann wrote: post #276
jacquesm wrote: post #225

Earlier quoted context omitted.

I've spent my whole life speaking multiple languages and this still trips me up every now and then, in fact quotes as such are a problem for me and I keep using them wrong, no idea why, it just won't register. So unless I slow down to 1/10th of my normal writing speed I will definitely make mistakes like that. Good we have proofreaders :)

(guessing you mean apostrophes) It's because they have two different uses (three if you count nested quotes, but those aren't common and are pretty easy to figure out), contractions and possession, and they seemingly collide on words like "its" where you'd think it could mean either. Not sure if you've already learned this (or if it helps), but English used to be declined, and its pronouns still are, e.g. they/their/…

His, hers, its

Re: ECC matters

#376

Post by lighttower »

cbanek wrote: post #77

As someone who has had to read thousands of random game crash reports from all over the interwebs (you know when Windows says you might want to send that crash log? like that), I totally agree. Of all the things to be worried about, like OS bugs, bad hardware configuration, etc. bad memory is one of those really troubling things. You look at the code and say "it's can't make it here, because this was set" but when yo…

Someone reads those reports!?! Wow, how do I write them to ensure someone who reads them takes them seriously?

Re: ECC matters

#377

Post by wtallis »

colejohnson66 wrote: post #317
marcosdumay wrote: post #72

Earlier quoted context omitted.

Keep in mind that Intel lies about its TDP.

They don’t. They just measure it differently than AMD. Intel measures at base clock, but AMD measures at sustained max clock IIRC. It’s definitely deceptive, but it’s not a lie as long as Intel tells you (which they do).

Intel's TDP numbers are at best an indicator of which product segment a chip falls into. They are wildly inaccurate and unreliable indicators of power draw under any circumstance. For example, here's a "58W" TDP Celeron that can't seem to get above 20W: https://twitter.com/IanCutress/status/1345656830907789312

And on the flip side, if you're building a desktop PC with a more high-end Intel processor, you will usually have to change a lot of motherboard firmware settings to get the behavior to resemble Intel's own recommendations that their TDP numbers are supposedly based on. Without those changes, lots of consumer retail motherboards default to having most or all of the power limits effectively disabled. So out of the box, a "65W" i7-10700 and a "125W" i7-10700K will both hit 190-200W when all 8 cores/16 threads are loaded.

If a metric can in practice be off by a factor of three in either direction, it's really quite useless and should not be quantified with a scientific unit like Watts.

Re: ECC matters

#378

Post by lighttower »

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…

Can you get decent battery life with this ecc memory in a laptop?

Re: ECC matters

#379

Post by apankrat »

cbanek wrote: post #77

As someone who has had to read thousands of random game crash reports from all over the interwebs (you know when Windows says you might want to send that crash log? like that), I totally agree. Of all the things to be worried about, like OS bugs, bad hardware configuration, etc. bad memory is one of those really troubling things. You look at the code and say "it's can't make it here, because this was set" but when yo…

Aye. I have an assert in the code that fronts a very pedantic test of the context. In all cases when this assert was tripped (and reported) an overnight memtest86 test surfaced RAM issues.

- Edit -

Also, bit flips in the non-ECC memory are _the_ cause of the "bitrot" phenomenon. That is when you write out X to a storage device, but you get Y when you read it back. A common explanation is that the corruption happens _at rest_. However all drives from the last 30+ years have FEC support, so in reality the only way a bit rot can happen is if the data is damaged _in transit_, while in RAM, on the way to/from the storage media.

So, if you ever decide if to get an ECC RAM, get it. It's very much worth it.

Re: ECC matters

#380

Post by mixmastamyk »

MarkusWandel wrote: post #194

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

A few years back memtest86 wouldn’t run on newer machines, has that been fixed?
Post reply on HN