3 ms·

I know that's not how it's sold (your "128GB" stick actually contains 144GB of memory if it's ECC), but that's dumb and drives up the cost. Needing two SKUs is

I know that's not how it's sold (your "128GB" stick actually contains 144GB of memory if it's ECC), but that's dumb and drives up the cost. Needing two SKUs is kind of the problem, and it's not a technical problem.

Thetawaves 6y ago
Needing an additional bit to store ECC data is not a technical problem?
- theginger 6y ago
  The point he is trying to make is you don't need additional bits, you just need bits, they could be additional, or they could be subtracted from what is available.
  - Thetawaves 6y ago
    How would this actually work? Memory access on your non-ecc processor is (for example) 64 bits wide. Your data is using all 64 bits. Perhaps you would only use 56 bits for user data and 8 bits of ecc data on every read? Suddenly you need two memory accesses to read your 64bit value?
    - stormbrew 6y ago
      I suppose you could have an extra dimm slot just for ecc storage, and only require it to be 1/8 the size of total ram on the normal slots. (I think there are probably issues with this in terms of how ddr itself actually works with its interleaving and adding a third channel to access from but I don't know enough about how it works to know for sure if that's the case)
      - jasonwatkinspdx 6y ago
        Separate channels are not timing locked. This would involve a lot more complexity and cost than the current practice. At the end of the day, electrical/computer engineers do actually generally know what they're doing.
- bcrl 6y ago
  Speed does not decrease with ECC memory -- you might be thinking of the extra cycle of latency associated with registered memory, and that's hardly a 100% penalty. Unbuffered ECC DIMMs have no penalty compared to non-ECC DIMMs. Shipping 72 bits to the CPU instead of 64 bits costs a bit more power, nothing more. Your desktop CPU already has all the transistors needed to handle ECC memory, they're just disabled in consumer SKUs.
robocat 6y ago
> and it's not a technical problem For a memory controller to add extra bits, they would have to come from somewhere. For every 64 bits (8 bytes read), you now need to read 72 bits (9 bytes). However “DIMMs are printed circuit boards that carry multiple packaged DRAMs and support 64bit or 72bit databus widths, the latter to enable eight error-checking and correction (ECC) bits to protect against single-bit errors.”. So now every read from 64 bit (non-ECC) DRAM now needs two reads, one for the 64 bits you want, and another to read the 8 bits ECC. If your access pattern is random, then you will slow down memory access by 100%. For long run sequential reads/writes the slow down will be 12.5% assuming you can lock the memory accesses for 9 sequential reads/writes (avoiding invalid memory states is essential!). The “cost” of ECC implemented by the memory controller is: * you lose 1/9th of your memory (as you point out) * the speed of your computer drops by up to 100% (speed of many operations is limited by random memory access speed, not CPU) * CPU atomic instructions for memory access are complicated https://en.wikipedia.org/wiki/Compare-and-swap https://en.wikipedia.org/wiki/Compare-and-swap and would also incur a further speed penalty in critical sections - which can very significant. The idea seems useful (clearly it would be a fantastic feature to be able to switch on if you suspect faulty memory) but there are likely technical reasons for why your idea is not implemented (not just price discrimination). > dumb That appears condescending to me. Generally you should assume people are smart. ECC RAM is designed by smart people to be the way it is and start with the assumption that if an idea isn’t implemented that perhaps there are good reasons why not? (Edited to make reply flow better. Disclaimer: I only have a very shallow knowledge of the design constraints, and I expect there are other more serious problems with the idea).

Thetawaves 6y ago

Needing an additional bit to store ECC data is not a technical problem?

theginger 6y ago
The point he is trying to make is you don't need additional bits, you just need bits, they could be additional, or they could be subtracted from what is available.
- Thetawaves 6y ago
  How would this actually work? Memory access on your non-ecc processor is (for example) 64 bits wide. Your data is using all 64 bits. Perhaps you would only use 56 bits for user data and 8 bits of ecc data on every read? Suddenly you need two memory accesses to read your 64bit value?
  - stormbrew 6y ago
    I suppose you could have an extra dimm slot just for ecc storage, and only require it to be 1/8 the size of total ram on the normal slots. (I think there are probably issues with this in terms of how ddr itself actually works with its interleaving and adding a third channel to access from but I don't know enough about how it works to know for sure if that's the case)
    - jasonwatkinspdx 6y ago
      Separate channels are not timing locked. This would involve a lot more complexity and cost than the current practice. At the end of the day, electrical/computer engineers do actually generally know what they're doing.
bcrl 6y ago
Speed does not decrease with ECC memory -- you might be thinking of the extra cycle of latency associated with registered memory, and that's hardly a 100% penalty. Unbuffered ECC DIMMs have no penalty compared to non-ECC DIMMs. Shipping 72 bits to the CPU instead of 64 bits costs a bit more power, nothing more. Your desktop CPU already has all the transistors needed to handle ECC memory, they're just disabled in consumer SKUs.

robocat 6y ago

> and it's not a technical problem For a memory controller to add extra bits, they would have to come from somewhere. For every 64 bits (8 bytes read), you now need to read 72 bits (9 bytes). However “DIMMs are printed circuit boards that carry multiple packaged DRAMs and support 64bit or 72bit databus widths, the latter to enable eight error-checking and correction (ECC) bits to protect against single-bit errors.”. So now every read from 64 bit (non-ECC) DRAM now needs two reads, one for the 64 bits you want, and another to read the 8 bits ECC. If your access pattern is random, then you will slow down memory access by 100%. For long run sequential reads/writes the slow down will be 12.5% assuming you can lock the memory accesses for 9 sequential reads/writes (avoiding invalid memory states is essential!). The “cost” of ECC implemented by the memory controller is: * you lose 1/9th of your memory (as you point out) * the speed of your computer drops by up to 100% (speed of many operations is limited by random memory access speed, not CPU) * CPU atomic instructions for memory access are complicated https://en.wikipedia.org/wiki/Compare-and-swap https://en.wikipedia.org/wiki/Compare-and-swap and would also incur a further speed penalty in critical sections - which can very significant. The idea seems useful (clearly it would be a fantastic feature to be able to switch on if you suspect faulty memory) but there are likely technical reasons for why your idea is not implemented (not just price discrimination). > dumb That appears condescending to me. Generally you should assume people are smart. ECC RAM is designed by smart people to be the way it is and start with the assumption that if an idea isn’t implemented that perhaps there are good reasons why not? (Edited to make reply flow better. Disclaimer: I only have a very shallow knowledge of the design constraints, and I expect there are other more serious problems with the idea).