Hacker News Reader

Comment by sys_64738 | Hacker News Reader

ECC memory is predominantly used in servers where failure absolutely must be identified and logged. The desktop market to a lesser extent due to lack of mission critical tasks being run from there.

View on HN

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.

That's the principle behind Gray Code counting: https://en.wikipedia.org/wiki/Gray_code

Not really. Gray codes are designed so that if you're counting correctly, only one bit flips at a time. But if you flip the wrong bit by accident, you'll end up with a completely different number, no way to tell a problem happened.

If you want to detect a bit flip, use parity.

That doesn't help if the memory is corrupted before the verification code is applied. (the code will simply put a signature on incorrect data)

Or after it's been checked. (time-of-check vs time-of-use)

Right, exactly. TCP protects us from data-corruption in network streams, and ECC protects us from data-corruption in RAM. I doubt any sort of software solution could practically compete against hardware ECC, even if it could be done it would presumably be disastrous for performance.

The best integrity checking is "end to end". The problem with non-ECC is that there are no "ends" that are trustworthy.

I guess in theory some software could produce signed data in CPU cache, and "commit" it to RAM as a verified block.

But the overhead would be enormous. Would you slow down your CPU by half in order to not pay 12.5% more for RAM?

Hmm, I wonder what SGX and similar do about this.

Those corner cases might occur rarely but are probably inconsequential given rate of occurrence versus rate of criticalness - it probably doesn't justify the markup for most. In a data center you're processing millions of transactions per minute so occurrence is much more impactful.

You need 1/8 more memory - that's real the cost. It's pretty much Intel's fault for the segmentation.

I would EASILY pay 12.5% more (that's the bit overhead) for memory that actually works.

If my data is fine being corrupted to save 12.5% on RAM costs, then why am I even bothering processing the data? Apparently it's worthless.

People today weigh the cost of maybe 16 vs 32GB on a mid-tier desktop. ~doubling the cost for twice the RAM. Yes, paying 12.5% more for ECC RAM is a no-brainer.

To be fair, if your save mechanism is just a straight memory dump with no checksums and validation. You have bigger issues.

Why does it matter if it =HAD= checksum, the numbers would have been altered prior to save. It means you store one but you get two when read later. If the format calculates immediate checksums on blocks it'd detect memory corruption at best. The extreme downside is that such a part is untestable under normal conditions, hard to maintain, and it costs more than the ECC in development.

That happens more than you think though. Most* things that output PNG are making an in-memory data structure and dumping it to disk.

Perhaps consumer-grade software that needs guarantees of correctness should be using error correction in software. For example, database records for financial software, DNS, e-mail addresses, etc.

Reply on news.ycombinator.com