Funny thing is, back in the days of the PC XT (8086/8088), AT 286 and 386, all (or most?) computers had parity check (9 bits RAM). I rather prefer a halt error than silent corruption.

Curious what your use case is that entails ECC? Are you currently being held back without it?

It's insane that we're still using systems without ECC RAM. As memory shrinks bit errors get progressively more common. The more memory you have the better chance of corruption as well of course.

Literally everything else that holds "data" has been using some form of error correction forever. Hard drives, SSD's, USB flash drives, file systems, databases, even network packets. Even HDMI uses error correction, and how important is momentary pixel corruption on a screen???

It's totally insane that we're not using ECC with such large amounts of RAM built on tiny processes. Its definitely just a cartel artificially maintaining a situation that's bad for everyone not selling server chips.

Exactly. A "one in a billion" event now happens with great regularity on a system with over a hundred billion of bits of memory.

Integrity of your data. Without ECC data in memory can become corrupted at any point.

It's usually just a single bit but say you are working with images, do you care if a single pixel changes its RGB value because of a memory error? A character in the metadata?

I do.

Unfortunately there is a hardware cartel which deliberately limits ECC to enterprise / server products so that they can inflate the price / their profit margin.

ECC RAM is more expensive to manufacture than non-ECC RAM but the price difference would be fairly minimal if ECC RAM were used everywhere - as it should.

Also any form of file that is easy to corrupt to a non-decodable state. Such as any binary save/config file, or any sort of file conversion or transferance. The data you transfer from location to location will always pass through memory, and in the case of converting that data to another format, it may not be possible to validate the destination format in relation to the original data.

Hypothetically, even with hash checks when transferring files, if the chunk of data read from the source file changes, that data will be used to calculate the hash sum, along with being written to the destination file. Meaning the hash sum would match the destination file anyways. You could even get wrong hash sums and think the transfer was wrong.

Really when memory can just 'change', anything can happen and there's no real good ways to get around it. ECC memory should just be everywhere.

Well I just had data corruption on my Intel NUC due to a stick of RAM failing. Had I had ECC the fault would most likely have been spotted right away. Instead it dragged on for a few months. Glad I kept multi-month backup sets.

Firefox crashed every now and then, but that's not something which raised any flags with me. Other than that the box seemed just fine. Then one day I couldn't boot anymore as the filesystem had been severely corrupted.

Ran memtest86 and sure enough, a span of addresses invariably generated errors in all tests.

This shouldn't de downvoted, it's a fair question. Just a few years ago ECC was widely considered an unnecessary belt-and-suspenders thing that made enterprise hardware expensive. I guess the general perception changed with the Rowhammer attack.

I don't think so. Well before Rowhammer, Google published their paper showing the high amount of memory errors they get.

What's changed is higher memory densities, making it even more important.

It only made things expensive because of low segmented volume. Otherwise it's a 10% bump on RAM and free on everything else.

Is the lack of a secure door to your property something that would hold you back? I doubt that. Still, secure doors are important.

Do you have blast doors installed home?

Anyway, not sure how exactly ECC relates to security. Is there any specific attack vector where it helps?

A blast door protects against explosions – a very unlikely scenario, that will happen to practically nobody. ECC protects against bit flips in RAM which happen significantly often ( https://www.cnet.com/news/google-computer-memory-flakier-tha... )

Your comparison is inadequate.

rowhammer, though it apparently can work around ecc.