Well, it uses 12.5% of the bytes for error correction instead of data storage, which is not very much overhead. Your 128GB becomes 112GB, which is still pretty good.
I also disagree that the benefits are meager. I have suffered from several computers with flaky memory (fine when you build the computer, flaky several years later; then you do an overnight memory test and find that indeed the memory has gone bad), and a strong software signal that "hey your memory is bad" is very actionable. You also have to think about it from a programming standpoint -- what happens if this variable isn't what I set it to? What if "for 1..10" is actually "for 1..2147483658"? Do you have time to debug that? How much data do you lose when you persist that to disk? To me it is insane to not get this nearly-free consistency check if you ever plan to persist any bytes in RAM to long-term storage. Even consumer GPUs have ECC memory these days. It's a no-brainer.
What surprises me is that the industry segments RAM sticks by ECC/not-ECC, when it's just a software function performed by the memory controller. I think everyone with a HEDT setup would be happy to enable ECC and get better reliability at the cost of 12% less RAM. I know I would be. (I built a Threadripper workstation recently and just couldn't get any reasonable prices on QVL'd ECC memory. So I skipped it and paid like $600 for 128GB of 3600MT/16-CAS memory... would be happy to flip a switch and have that be only 112GB.)
The reason why ECC isn't widespread is it's because it's used to segment the market. Home users are cost sensitive, so hardware vendors have to think of ways to get server users to not buy home user equipment. ECC is one of these levers. That's all there is to it. Everyone would have ECC if it were a mere 12.5% more expensive.
This is not how ECC ram works. 128GB of ram does not change to 112GB with ECC. 128GB of ram with ECC will invariably be 144GB.
Standard memory modules become (a multiple of) 9 bits wide, with the additional bit stored near the other 8 bits.
Which is still 12.5%. Which for most people wouldn't be a problem since ram is a fraction of the system price (so it might only raise the price of the machine 3% if the ram is 1/3 of the total BOM).
The problem is _INTEL_ deciding its a premium feature, and the memory manufactures charging 50%+ more for 12.5% more hardware.
So instead of being a couple percent of the system cost, it ends up being a noticeable double digit percentage.
Of course none of this explains why apple/etc haven't done it in their phones.
You seem to be commenting on cost figures, but have not actually identified the cost / sales volume relationship.
ECC memory physically requires additional wires, necessitating different parts that don't sell at the same volumes.
Not sure what volume has to do with it, if the whole market is ECC.
And as far as "wires", traces are basically free as long as they don't force additional pcb layers, which shouldn't be the case given the careful pin/ddr chip/processor designs focused on exactly that. The extra pins are there regardless, and in the past so were the "wires" given that CBx/DMx pins were muxed. Further, packetized ram interfaces have been known to bury the error correction in the protocol same as PCIe/etc. Meaning its a slight efficiency loss.
Look at it this way, every part of the system _EXCEPT_ the ram has some kind of error correction on it at this point. Its a cheap way to not only increase robustness but its also a security mechanism.
If I were guessing, I would say that DDR5 is the last version that isn't ECC end to end, the idea that the manufactures can shrink the dies at the cost of some BER and make it up with a bit of embedded ECC will just be to tempting. Particularly with AMD on the rise, intel will have a much harder time playing product segmentation games if AMD doesn't do the same.
It's not just about the cost of a pcb trace. A wider parallel bus means more potential skew which means either relaxing timing or tighter tolerances. The notional 12% cost for the extra ram bank and related hardware may not seem like much, but the margins on commodity computing equipment are razor thin. Consumers don't and won't buy on the basis of ECC being on a sticker on the box, so manufacturers correctly conclude that they should cut the feature or be undercut on price.
deleted 6y ago
[deleted]
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.
> Do you have time to debug that?
By the way, for detection you don't need the full error correcting code, but you can use an error detecting code which can use fewer bits.
Unbuffered ECC RAMs are expensive because of lower demand. Registerd ECC RAMs especially used ones are dirt cheap thanks to huge amount of servers.
> ECC adds significant cost
Does it, though? I don't remember all the prices from when I was researching memory close to a year ago for a new PC, but one big notable difference between ECC and non-ECC I've seen is that almost all non-ECC sticks are overclocked. You buy something rated at 2667MHz, and you actually get is e.g. 1833MHz chips overclocked at that speed. Which makes them cheaper. But I'd expect non-overclocked non-ECC sticks to be that far in pricing to ECC sticks (well, apart from the obvious difference they'd have more chips). And because the market is focused on cheap non-ECC sticks, they don't do cheaper ECC overclocked sticks, but there is no reason they couldn't make them. There aren't that many ECC unbuffered sticks already, it's easier to find registered ones. Essentially, the market is skewed by Intel not supporting ECC on non-Xeons.
Ironically, ECC is great to have for manual overclocking as you will know when you pushed your system too far - even if most things work fine and problems only happen with some demanding workloads. Without ECC you'd likely falsely assume that the software / OS / drivers are buggy since everything else works.
Dunno, I've notice it being a pretty minimal step up in price. Over a few generations the E3-1230 (quad core/8 threads) was cheaper then the similar I7. The clock speed is slightly less (100-200 Mhz), but I figure that's reasonable if you are going for a nice, cool, and reliable CPU.
So I save $50 on the CPU and that just about covers the ram/motherboard premium.
> 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).