There's UDIMMs (typical RAM from desktops), and then RDIMMs (Registered), and LRDIMMs (Load-Reduced DIMM).
Because RDIMMs and LRDIMMs are only used on servers, they're all ECC / Error Correction just implicitly. At least, I've never seen an RDIMM or LRDIMM missing ECC.
You used to see it in workstation builds, although I can't remember the last time I saw that configuration lol. It's certainly not something you'd see often even then.
The workstation market is split between platforms using RDIMMs and UDIMMs (and has been for a very long time), but the RDIMMs still always have ECC and the UDIMMs for systems branded as workstations almost always have ECC.
You’re right, and I was being imprecise. I was trying to convey that the functionality was entirely contained within the chip/module unlike traditional ECC which passes the parity data back to the CPU.
The parent said the chances of a single bit flipping are too high without it, they are, which is why it’s in the spec :) These densities wouldn’t be possible without it.
All DDR5 has ECC built into the modules for it to reach parity DDR4.
ECC memory modules are better because they can fix and report errors, the base DDR5 DIMM will hand you a piece of memory with multi-bit corruptions that it couldn't fix. The ECC DIMM will fix larger errors and tell you about each detected corruption.
But there are ECC DIMMs with even better ECC. DDR5 moved the DIMMs from one 64-bit channel to two 32-bit channels. ECC DDR4 you'd protect 8 memory dies with 1 memory die holding the ECC, your computer will identify it as 72-bit memory. ECC DDR5 you protect the 4 memory dies in the half channel with a dedicated 5th die on each channel. Some ECC DDR5 will have 80-bit ECC, some will have 72-bit ECC. You want the 80-bit ECC because it stores 8 more bits of ECC for your memory controller to correct errors.
I would add that "has ECC" is even more complicated than you've implied here. There are many ways to detect and correct DRAM errors, and with the memory controllers moved into the CPU the features you get depend on your CPU vendor, firmware, and operating system. To get the most out of a current Xeon SP, for example, you want 10x4 DDR5, that provides 8 code bits with each 32 bits of data. All of the players in the business have patents on some part of ECC, so you get a grab bag of techniques on different platforms.
It really isn't that simple. For example, the distinction you're ignoring from the comments you replied to is the question of correcting a single error among how many bits: one bit error across the full 64-bit width of a DIMM, or one bit error per each 32-bit sub-channel now that DDR5 has split the DIMM in a way that previous desktop memory standards don't.
Where a non-ECC DIMM is usually 8 DRAM chips (64 bits) and in DDR4 or earlier and an ECC DIMM would be 9 DRAM chips (72 bits), now with DDR5 can have either 9 DRAM chips or 10 DRAM chips (80 bits).
The question of whether ECC protection is strong enough to provide SECDED also is insufficient to address the complexities of having ECC protection only on the link, or end-to-end via sideband or in-band ECC, or using a combination of separately implemented link ECC and on-die ECC.
> the complexities of having ECC protection only on the link
That's not SECDED, since it can't correct a bitflip that occurs somewhere other than on the link, nor can it detect a double bitflip in those situations.
> That's not SECDED, since it can't correct a bitflip that occurs somewhere other than on the link
You're just making up arbitrary rules. The term SECDED does not incorporate any guarantees about which part of a system it applies to. It's just a mathematical statement about the strength of the ECC in use plus the implication that detectable but uncorrectable errors are reported.
What you're looking for requires more words to fully specify, probably including the term "end to end".
Your mantra is sort of hilarious because with current technology SECDEC is the worst ECC you can buy. If that's what you are getting on a DDR5 server today, the most likely reason is your integrator has made a mistake.
There seems to be some confusion in the replies to your post.
What I’ve read is that DDR5 has “on-die ECC” which means that the module itself handles the error correction, but then it can not handle errors that happen in transit to the CPU as full ECC can.
There are DDR5 full-ECC modules that would be real equivalents to DDR4 ECC.
> When the latest version of DDR memory – DDR5 – was introduced in 2020, marketing campaigns
got one important fact wrong. DDR5 UDIMM, the regular desktop RAM we’re all familiar with,
was touted as having “built-in” Error Correcting Code (ECC). Not true. What it has is built-in data
checking, which is a very different feature that shouldn’t be confused with traditional ECC.
For that, your customers will need DDR5 ECC UDIMM memory.
Additionally, on-die ECC isn't unique to DDR5; it's a necessity for any DRAM built on the most recent high-density fab processes. It was used for at least some LPDDR4 memories, and probably most or all LPDDR5.
As of 2015 when I worked there, Boise was almost entirely R&D. Since then, they did a fab expansion, and I'm not sure if any of that ended up for production.
Production was in Manassas, Virginia as well as numerous locations in Asia.
Technically die is the singular and dice is the plural form of the cubes you roll for numbers.
Then there's the other die, as in die-cast. I think these are typically referred to as dies in the plural. I'm not sure if this terminology is still in use, it seems to have been replaced with mold.
Then the other other die, referring to the fragment of silicon inside an integrated circuit. I've seen dice used more commonly, but both forms are in active use.
It's one of those frustrating inconsistencies of the English language.
> Then there's the other die, as in die-cast. I think these are typically referred to as dies in the plural. I'm not sure if this terminology is still in use, it seems to have been replaced with mold.
I think die is still used when referring to metal stamping equipment and similar, but casting equipment is usually referred to with mold.
Linguistic drift IMHO. Formally, "dice" is the plural of "die". Less formally, "dice" are cubes with numbers on them and "die" is a completely separate word.
Yeah Languages with histories of adult learning have been argued to be morphologically simpler, less redundant, and more regular/transparent [2], [7], [28]–[30].
Native speakers are of course also very likely to pluralize nouns in the regular way when they don't know the irregular form. Usually, only very common nouns can sustain irregular pluralization. Perhaps dice carries on at all because it is often used both as the singular and plural.
I can't see any reason to think that native speakers are changing their patterns much because of what non-native speakers do or understand.
>> The demand for large memory capacity RDIMMs is being primarily driven by the sudden emergence of large-language models (LLMs) for generative AI and increasing CPU core counts.
I know LLMs are undergoing rapid change, but what if someone (say Apple) wanted to commit a large model to an actual masked ROM? What kind of density can be achieved on a similar process as DRAM, and what kind of interface would such a thing use?
No one uses ROM anymore. Its all Flash RAM, which is denser, cheaper, lower-power in practice. And Flash is likely too slow in any case, so people will prefer DRAM.
50 comments
[ 3.6 ms ] story [ 100 ms ] threadThis could be a great product but the chance of even one bit randomly flipping is far too high.
Also if you look at the picture, there's five columns of packages per channel.
There's UDIMMs (typical RAM from desktops), and then RDIMMs (Registered), and LRDIMMs (Load-Reduced DIMM).
Because RDIMMs and LRDIMMs are only used on servers, they're all ECC / Error Correction just implicitly. At least, I've never seen an RDIMM or LRDIMM missing ECC.
The parent said the chances of a single bit flipping are too high without it, they are, which is why it’s in the spec :) These densities wouldn’t be possible without it.
ECC memory modules are better because they can fix and report errors, the base DDR5 DIMM will hand you a piece of memory with multi-bit corruptions that it couldn't fix. The ECC DIMM will fix larger errors and tell you about each detected corruption.
But there are ECC DIMMs with even better ECC. DDR5 moved the DIMMs from one 64-bit channel to two 32-bit channels. ECC DDR4 you'd protect 8 memory dies with 1 memory die holding the ECC, your computer will identify it as 72-bit memory. ECC DDR5 you protect the 4 memory dies in the half channel with a dedicated 5th die on each channel. Some ECC DDR5 will have 80-bit ECC, some will have 72-bit ECC. You want the 80-bit ECC because it stores 8 more bits of ECC for your memory controller to correct errors.
Micron isn't known for making 80-bit DIMMs.
It's really simple: just demand SECDED.
That's all you need to know, one acronym, SECDED.
https://cr.yp.to/hardware/ecc.html
Single Error Correction, Double Error Detection.
BTW, this sort of ECC fraud has been going on since the 1990's at least. It isn't going to just go away. Learn what SECDED is and demand it.
On Linux:
Where a non-ECC DIMM is usually 8 DRAM chips (64 bits) and in DDR4 or earlier and an ECC DIMM would be 9 DRAM chips (72 bits), now with DDR5 can have either 9 DRAM chips or 10 DRAM chips (80 bits).
The question of whether ECC protection is strong enough to provide SECDED also is insufficient to address the complexities of having ECC protection only on the link, or end-to-end via sideband or in-band ECC, or using a combination of separately implemented link ECC and on-die ECC.
> the complexities of having ECC protection only on the link
That's not SECDED, since it can't correct a bitflip that occurs somewhere other than on the link, nor can it detect a double bitflip in those situations.
SECDED. Just ask for SECDED.
Even the Linux kernel knows about this:
SECDED. Just ask for SECDED.You're just making up arbitrary rules. The term SECDED does not incorporate any guarantees about which part of a system it applies to. It's just a mathematical statement about the strength of the ECC in use plus the implication that detectable but uncorrectable errors are reported.
What you're looking for requires more words to fully specify, probably including the term "end to end".
What I’ve read is that DDR5 has “on-die ECC” which means that the module itself handles the error correction, but then it can not handle errors that happen in transit to the CPU as full ECC can.
There are DDR5 full-ECC modules that would be real equivalents to DDR4 ECC.
> When the latest version of DDR memory – DDR5 – was introduced in 2020, marketing campaigns got one important fact wrong. DDR5 UDIMM, the regular desktop RAM we’re all familiar with, was touted as having “built-in” Error Correcting Code (ECC). Not true. What it has is built-in data checking, which is a very different feature that shouldn’t be confused with traditional ECC. For that, your customers will need DDR5 ECC UDIMM memory.
— Intel, “Error Correcting Code (ECC) vs. Built-in Data Checking”: https://www.intel.com/content/www/us/en/content-details/7549...
Production was in Manassas, Virginia as well as numerous locations in Asia.
Then there's the other die, as in die-cast. I think these are typically referred to as dies in the plural. I'm not sure if this terminology is still in use, it seems to have been replaced with mold.
Then the other other die, referring to the fragment of silicon inside an integrated circuit. I've seen dice used more commonly, but both forms are in active use.
It's one of those frustrating inconsistencies of the English language.
I think die is still used when referring to metal stamping equipment and similar, but casting equipment is usually referred to with mold.
Don't they sound the same?
dies daɪz
dice daɪs
I never asked, but I want to believe their internal representation of “1D6” is one-dice-six.
Sorta like reading “1 x 6” as “one _times_ six” instead of “one _time_ six”
Words are fun.
https://journals.plos.org/plosone/article?id=10.1371/journal...
I can't see any reason to think that native speakers are changing their patterns much because of what non-native speakers do or understand.
Or even better "128 GByte ... 32 Gbit"
I know LLMs are undergoing rapid change, but what if someone (say Apple) wanted to commit a large model to an actual masked ROM? What kind of density can be achieved on a similar process as DRAM, and what kind of interface would such a thing use?
But you also have input dependent activations. You need RAM for these.