4 ms·

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

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.

dijit 6y ago
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.
- MaxBarraclough 6y ago
  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.
  - KingMachiavelli 6y ago
    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.
    - mark-r 6y ago
      That's the principle behind Gray Code counting: https://en.wikipedia.org/wiki/Gray_code https://en.wikipedia.org/wiki/Gray_code
      - Dylan16807 6y ago
        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.
    - knorker 6y ago
      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)
      - MaxBarraclough 6y ago
        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.
        knorker 6y ago
        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.
- sys_64738 6y ago
  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.
  - xxs 6y ago
    You need 1/8 more memory - that's real the cost. It's pretty much Intel's fault for the segmentation.
  - knorker 6y ago
    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.
- jkbbwr 6y ago
  To be fair, if your save mechanism is just a straight memory dump with no checksums and validation. You have bigger issues.
  - xxs 6y ago
    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.
  - dijit 6y ago
    That happens more than you think though. Most* things that output PNG are making an in-memory data structure and dumping it to disk.
- projektfu 6y ago
  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.

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.

dijit 6y ago

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.

MaxBarraclough 6y ago
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.
- KingMachiavelli 6y ago
  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.
  - mark-r 6y ago
    That's the principle behind Gray Code counting: https://en.wikipedia.org/wiki/Gray_code https://en.wikipedia.org/wiki/Gray_code
    - Dylan16807 6y ago
      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.
  - knorker 6y ago
    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)
    - MaxBarraclough 6y ago
      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.
      - knorker 6y ago
        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.
sys_64738 6y ago
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.
- xxs 6y ago
  You need 1/8 more memory - that's real the cost. It's pretty much Intel's fault for the segmentation.
- knorker 6y ago
  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.
jkbbwr 6y ago
To be fair, if your save mechanism is just a straight memory dump with no checksums and validation. You have bigger issues.
- xxs 6y ago
  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.
- dijit 6y ago
  That happens more than you think though. Most* things that output PNG are making an in-memory data structure and dumping it to disk.
projektfu 6y ago
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.