undefined | Better HN

0 pointssupernovae5y ago0 comments

I've got nearly 30 years of experience and not once has non ECC memory lead to corruption. Maybe a crash, maybe a panic, maybe a kernel dump...

But.. in all my time operating servers over 3 decades, it's always been bad drivers, bad code and problematic hardware that's caused most of my headaches.

Have i seen ECC error correction in logs? yeah.. I don't advocate against it but, i've found for most people you design around multiple failure scenarios more than you design around preventing specific ones.

Take the average web app - you run it on 10 commodity systems and distribute the load.. if one crashes, so what. Chances are, a node will crash for many more reasons other than memory issues.

If you have an app that requires massive amounts of ram or you do put all of your begs in one basket, then ECC makes sense...

I just know i like going horizontal and I avoid vertical monoliths.

0 comments

ptx5y ago

> if one crashes, so what

Crashes might not matter, but silent data corruption does. The owner/user of that data will care when they eventually discover that it at some point mysteriously got corrupted.

ajnin5y ago

> I've got nearly 30 years of experience and not once has non ECC memory lead to corruption

How do you know?

supernovaeOP5y ago

Complex systems require constant probing. You always probe. If you stop probing to look for errors because you assumed ECC fixed it for you, then you're probably at more risk of corruption vs accepting the fact there will be an infinite risk of error and being defensive against all types.

louwrentius5y ago

The problem with memory corruption is not just crashes, those are the more benign outcomes.

The real killer is data corruption. Houw would you even begin to know that data is corrupted until it is too late?

supernovaeOP5y ago

Corruption can happen for any number of reasons. ECC doesn't correct for human error, protocol error, coding error, logic error, type error so on and so forth.

Again, I don't advocate NOT using ECC, but i'd say in complex systems, never assume ECC alone is enough... and if ECC becomes your champion cause, how could you enforce it through every device that touches data, provides data, consumes data or injects data?

j / k navigate · click thread line to collapse

0 pointssupernovae5y ago0 comments

I've got nearly 30 years of experience and not once has non ECC memory lead to corruption. Maybe a crash, maybe a panic, maybe a kernel dump...

But.. in all my time operating servers over 3 decades, it's always been bad drivers, bad code and problematic hardware that's caused most of my headaches.

Take the average web app - you run it on 10 commodity systems and distribute the load.. if one crashes, so what. Chances are, a node will crash for many more reasons other than memory issues.

If you have an app that requires massive amounts of ram or you do put all of your begs in one basket, then ECC makes sense...

I just know i like going horizontal and I avoid vertical monoliths.

0 comments

ptx5y ago

> if one crashes, so what

Crashes might not matter, but silent data corruption does. The owner/user of that data will care when they eventually discover that it at some point mysteriously got corrupted.

ajnin5y ago

> I've got nearly 30 years of experience and not once has non ECC memory lead to corruption

How do you know?

supernovaeOP5y ago

louwrentius5y ago

The problem with memory corruption is not just crashes, those are the more benign outcomes.

The real killer is data corruption. Houw would you even begin to know that data is corrupted until it is too late?

supernovaeOP5y ago

Corruption can happen for any number of reasons. ECC doesn't correct for human error, protocol error, coding error, logic error, type error so on and so forth.

j / k navigate · click thread line to collapse