4 ms·

ECC matters, even on the desktop, it's not even a discussion, to me. If you think it doesn't matter: how do you know? If you don't run with ECC memory, you'll

ECC matters, even on the desktop, it's not even a discussion, to me. If you think it doesn't matter: how do you know? If you don't run with ECC memory, you'll never know if memory was corrupted (and recovered). That blue screen, that sudden reboot, that program crashing. That corrupted picture of your kid. Who knows. I'll tell you, who knows. God damn every sysadmin (or the modern equivalent) can tell you how often they get ECC errors. And at even a small scale you'll encounter them. I have, on servers and even on an SAN Storage controller, for crying out loud. If you care about your data, use ECC memory in your computers.

supernovae 6y ago
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.
- ptx 6y 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.
- louwrentius 6y 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?
  - supernovae 6y 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?
- ajnin 6y ago
  > I've got nearly 30 years of experience and not once has non ECC memory lead to corruption How do you know?
  - supernovae 6y 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.
alkonaut 6y ago
I know what it does, but I still don’t care (so long as it costs money or even 1% performance). It’s a tradeoff between money/performance and the frequency of crashes, corruption etc. Bit rot is just one of many threats to my data. Backups take care of that as well as other threats like theft, fire, accidental deletion. This is similar to my reasoning around the recent side channel attacks on intel CPUs. If I had a choice I’d like to run with max performance without the security fixes even though it would be less secure. Not because I don’t care about security but because 1% or 5% perf is a lot and I’d rather simply avoid doing anything security critical on the machine entirely than take that hit.
- mark-r 6y ago
  Backups can't fix what was already corrupted when it was written to disk.
- louwrentius 6y ago
  > Bit rot is just one of many threats to my data. Backups take care of that as well as other threats like theft, fire, accidental deletion. No, that's the big mistake people make: backups just backup bit-rotted data, until it is too late and the last good version is rotated out and lost forever.
  - alkonaut 6y ago
    I’m aware. But the risk is extremely small (and 99.9% of important data is not created on the machine but goes directly from e.g iOS camera to backup). My desktop machine is basically a gaming rig with disposable data. Hence the “performance over integrity”. I also never rotate anything out. Every version of everything is in the backups. Storage is that cheap these days.
    - xxs 6y ago
      >My desktop machine is basically a gaming rig ...unlike all the accountant machines which are just standard desktop grade ones that have invoices entered from their keyboards. >Hence the “performance over integrity”. If anything ECC would be better for performance, as it'd allow to clock memory higher. It's a mystery how Intel has managed to convince people ECC = enterprise/server market. The real cost of ECC is 1/8 more memory (and datatraces on the motherboard)... and if anything, virtually all intel cpus have the needed support/transistors in the memory controller, it's just desktop variants have that part fused off on purpose.

supernovae 6y ago

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.

ptx 6y 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.
louwrentius 6y 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?
- supernovae 6y 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?
ajnin 6y ago
> I've got nearly 30 years of experience and not once has non ECC memory lead to corruption How do you know?
- supernovae 6y 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.

alkonaut 6y ago

I know what it does, but I still don’t care (so long as it costs money or even 1% performance). It’s a tradeoff between money/performance and the frequency of crashes, corruption etc. Bit rot is just one of many threats to my data. Backups take care of that as well as other threats like theft, fire, accidental deletion. This is similar to my reasoning around the recent side channel attacks on intel CPUs. If I had a choice I’d like to run with max performance without the security fixes even though it would be less secure. Not because I don’t care about security but because 1% or 5% perf is a lot and I’d rather simply avoid doing anything security critical on the machine entirely than take that hit.

mark-r 6y ago
Backups can't fix what was already corrupted when it was written to disk.
louwrentius 6y ago
> Bit rot is just one of many threats to my data. Backups take care of that as well as other threats like theft, fire, accidental deletion. No, that's the big mistake people make: backups just backup bit-rotted data, until it is too late and the last good version is rotated out and lost forever.
- alkonaut 6y ago
  I’m aware. But the risk is extremely small (and 99.9% of important data is not created on the machine but goes directly from e.g iOS camera to backup). My desktop machine is basically a gaming rig with disposable data. Hence the “performance over integrity”. I also never rotate anything out. Every version of everything is in the backups. Storage is that cheap these days.
  - xxs 6y ago
    >My desktop machine is basically a gaming rig ...unlike all the accountant machines which are just standard desktop grade ones that have invoices entered from their keyboards. >Hence the “performance over integrity”. If anything ECC would be better for performance, as it'd allow to clock memory higher. It's a mystery how Intel has managed to convince people ECC = enterprise/server market. The real cost of ECC is 1/8 more memory (and datatraces on the motherboard)... and if anything, virtually all intel cpus have the needed support/transistors in the memory controller, it's just desktop variants have that part fused off on purpose.