> There is no world where accepting data corruption in order to save 3% cost is a reasonable tradeoff.

It is if you're doing something where corruption is detectable after the fact, and happens rarely enough that redoing affected work adds less than 3% overhead.

▲

zargon 3 days ago | parent [-]

If you don't have ECC, you don't even know that your CPU is executing the correct code. There goes the "detectable" part.

▲

tbrownaw 2 days ago | parent | next [-]

There's a decent amount of distributed stuff that has a design principle of not trusting the hardware it's running on.

▲

fvwqcecvq 2 days ago | parent | prev [-]

DRAM is just one level in the memory hierarchy and it can absolutely be tested by the other levels in the system. It won't be continually monitored, and there will be a performance penalty, and it's a PITA, but it can definitely be done without hardware ECC. Even some of that can be minimized as most tests are statistical in nature anyway.

	▲	adrian_b 2 days ago \| parent [-]
		If you do not monitor it continuously, you achieve nothing, because the memory errors happen seldom and unpredictably. Without ECC, you need a custom operating system, which will compute some error detection code, e.g. a CRC, for each read-only memory page, i.e. including all code pages and constant pages, and all cached but not dirty file system pages, and which will check the CRC codes periodically in the background. That would still leave the read-write data segments unprotected, though on those some errors may be benign, if the locations are overwritten later without being read again.