[HN Gopher] Micron Introduces 128 GB DDR5-8000 RDIMMs with Monol...
___________________________________________________________________
Micron Introduces 128 GB DDR5-8000 RDIMMs with Monolithic 32 GB Die
Author : rbanffy
Score : 85 points
Date : 2023-11-13 13:04 UTC (9 hours ago)
(HTM) web link (www.anandtech.com)
(TXT) w3m dump (www.anandtech.com)
| yardie wrote:
| Hmm. Ctrl-F "ECC": 0 results found.
|
| This could be a great product but the chance of even one bit
| randomly flipping is far too high.
| formerly_proven wrote:
| RDIMM
|
| Also if you look at the picture, there's five columns of
| packages per channel.
| dragontamer wrote:
| RDIMMs are implicitly ECC.
|
| 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.
| parl_match wrote:
| 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.
| wtallis wrote:
| 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.
| arcticbull wrote:
| All DDR5 has ECC built into the modules.
| whaleofatw2022 wrote:
| I thought that was per chip ECC not per module? (May be wrong
| on that)
| arcticbull wrote:
| 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.
| MaKey wrote:
| There are DDR5 modules with traditional ECC though, which
| the parent poster presumably meant.
| undersuit wrote:
| 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.
|
| Micron isn't known for making 80-bit DIMMs.
| jeffbee wrote:
| 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.
| crotchfire wrote:
| ECC is not complicated. Manufacturers pretend it's
| complicated in order to sell you inferior product at
| inflated prices.
|
| 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: # cat
| /sys/devices/system/edac/mc/mc*/*/edac_mode SECDED
| SECDED SECDED SECDED SECDED
| SECDED SECDED SECDED
| wtallis wrote:
| 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.
| crotchfire wrote:
| It's really that simple.
|
| > 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:
| # cat /sys/devices/system/edac/mc/mc1/csrow3/edac_mode
| SECDED
|
| SECDED. Just ask for SECDED.
| wtallis wrote:
| > 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".
| jeffbee wrote:
| 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.
| AlbertoGP wrote:
| 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._
|
| -- Intel, "Error Correcting Code (ECC) vs. Built-in Data
| Checking": https://www.intel.com/content/www/us/en/content-
| details/7549...
| wtallis wrote:
| 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.
| jakobson14 wrote:
| Can't wait to see another round of rowhammer papers
| trashing these things. XD
| jacquesm wrote:
| That's mostly because otherwise they wouldn't be reliable
| enough to use.
| jauntywundrkind wrote:
| Also awaiting word on MCR-DIMM (multiplexed combined rank dimms)
| which I think also allow a sizable boost, but via fan out instead
| of huge dies.
| rwmj wrote:
| These are manufactured in the US? (In Boise Idaho I think).
| DavidPeiffer wrote:
| 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.
| haunter wrote:
| Some interesting comments about the plural of die, apparently all
| three forms are commonly used (die, dies, dice)
| polishdude20 wrote:
| Dice? That's if you're talking about rolling the dice. Is it
| really used for these types of "dies"?
| calamari4065 wrote:
| _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.
| Finnucane wrote:
| In all my years in publishing, I've never heard anyone refer to
| jacket/spine stamping dies as dice.
| MakeThemMoney wrote:
| > Heard
|
| Don't they sound the same?
| pwagland wrote:
| Funnily enough, I would argue that dice and dies sound
| different, phonetically:
|
| dies daIz
|
| dice daIs
| HNDen21 wrote:
| To me the i sound is shorter for dice versus dies
| Finnucane wrote:
| Not in an email. Also, no, the pronunciation is distinct.
| At least around here.
| ooterness wrote:
| 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.
| someone7x wrote:
| I've heard "dice" for singles: you'll need to roll one dice
| here.
|
| 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.
| dist-epoch wrote:
| More and more English speakers (and readers) are not native.
| They are more likely to use (and understand) -s plurals.
| Erratic6576 wrote:
| Yeah Languages with histories of adult learning have been
| argued to be morphologically simpler, less redundant, and
| more regular/transparent [2], [7], [28]-[30].
|
| https://journals.plos.org/plosone/article?id=10.1371/journal.
| ..
| jeffbee wrote:
| The refresh power alone must be 5-10W right?
| crotchfire wrote:
| Title should say "32 Gb" not "32 GB".
|
| Or even better "128 GByte ... 32 Gbit"
| phkahler wrote:
| >> 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?
| dragontamer wrote:
| 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.
| dist-epoch wrote:
| You can store the weights in ROM.
|
| But you also have input dependent activations. You need RAM for
| these.
___________________________________________________________________
(page generated 2023-11-13 23:01 UTC)