[HN Gopher] Asgard launches world's first DDR5-9600 DIMMs
       ___________________________________________________________________
        
       Asgard launches world's first DDR5-9600 DIMMs
        
       Author : apsec112
       Score  : 75 points
       Date   : 2024-09-18 02:56 UTC (20 hours ago)
        
 (HTM) web link (www.tomshardware.com)
 (TXT) w3m dump (www.tomshardware.com)
        
       | pureheartlover wrote:
       | China based firm named Asgard with product names like Thor? Whats
       | going on here?
        
         | blackeyeblitzar wrote:
         | This is happening a lot in many product categories as a way to
         | market effectively for international audiences, without some of
         | the mistakes Chinese firms have historically made. Borrowing
         | from other cultures is easier. For example in audio, Hifiman is
         | a Chinese audio company that previously used alphanumeric names
         | for their headphones but now uses various Hindu or Sanskrit (?)
         | words to name their headphones and give them more of a "theme".
        
           | guruprasadah wrote:
           | From a quick glance at the website, the only two such
           | products I can see are the "Susvara" (meaning "with notes")
           | headphones and "Deva" (meaning "god") series headphones. Both
           | of those words are Sanskrit. Their hindi equivalents are
           | quite similar sounding (Susvar and Dev).
        
             | govg wrote:
             | They also sell/have sold the Arya, the Sundara, and the
             | Ananda.
        
         | stepupmakeup wrote:
         | I assumed it's to attach to the "as" naming prefix, asus,
         | asrock, asmedia, etc.
        
           | PokemonNoGo wrote:
           | What does that prefix mean?
        
             | Veliladon wrote:
             | Nothing. It's Pegasus with the first two letters removed so
             | they'd be at the top of the phone book when we used phone
             | books way back in 1989.
        
         | shiroiushi wrote:
         | It's a big step up from names like FDSOOJVX.
        
         | coffeebeqn wrote:
         | Heck, If I look real hard I might even find some California
         | based companies that don't pull exclusively from ancient
         | Californian lore.
        
           | deaddodo wrote:
           | The US can trace its lineage directly back to Europe. And
           | many of the companies in the US are founded by recent
           | immigrants (0-2 generations, worldwide), so it makes sense
           | that it would have a varied history to pull from that
           | includes European mythology. The same can't really be said of
           | China.
           | 
           | That being said, ancient mythology isn't something worth
           | gatekeeping. And anyone who gets _real_ uppity about
           | (specifically) Norse or Celtic mythology instantly starts
           | triggering  "closet/academic racist" vibes.
        
         | voytec wrote:
         | Stargates and wormholes.
        
         | zo1 wrote:
         | Marketing... These not-so-famous-yet Chinese firms have picked
         | up what the West has been doing and are trying to cut out the
         | middle-man. Essentially the West's MO has been to buy cheap no-
         | name generic stuff from china, have them
         | colored/branded/packaged, and then slap on all the necessary
         | product packaging stuff on the packaging (including a "Name").
         | Essentially acting as a middle-man that doesn't actually
         | produce the product, barely does any QA and just adds a thin
         | veneer of this being an actual "company" that manufactures and
         | sells this product. Sometimes they use a fancy term like "white
         | labeling".
         | 
         | Here is such a company in the South African context that's
         | super obvious about it:
         | https://www.loot.co.za/search?cat=b&brandcode/leisurequip
        
         | nicman23 wrote:
         | they are sg1 fans
        
       | ac29 wrote:
       | What goes unsaid in the article is that this will likely only
       | work with Intel's Arrow Lake? Arrow Lake isnt being launched
       | until next month though, so official specs are not available yet.
       | And the full 9600 speed will very likely require overclocking.
       | 
       | It doesnt appear Zen5 can get anywhere close those speeds.
        
         | wtallis wrote:
         | These are part of a new generation of DDR5 modules that add a
         | clock driver to the module itself, rather than relying entirely
         | on the clock signal coming all the way from the CPU's memory
         | controller. That is expected to _significantly_ change the game
         | for DDR5 overclocking, and expectations based on the
         | limitations of configurations lacking the clock drivers may not
         | be accurate. I expect we 'll see 6+ months of firmware tuning
         | before we have a clear picture of what each platform is
         | ultimately capable of, but early on the focus will be on Intel
         | platforms.
        
           | rowanG077 wrote:
           | How does that work? I imagine you now have the feed to clock
           | from ram back to the CPU? Or does it synchronize two local
           | clocks somehow?
        
             | Gracana wrote:
             | The clock redriver uses a phase locked loop to generate a
             | few identical clock signals for use by the DRAM chips on
             | the module. This same tech is also used for clock
             | multipliers and dividers throughout digital systems.
             | 
             | Rambus has details on their "DDR5 client clock driver"
             | here: https://www.rambus.com/memory-interface-
             | chips/ddr5-client-di...
        
             | Numerlor wrote:
             | This anandtech article seems to be a decent summary of what
             | it's doing, the JEDEC JESD82-531A.01 spec is also freely
             | available (with registration) if you're feeling adventurous
             | 
             | https://www.anandtech.com/show/21455/making-desktop-
             | ddr5-eve...
        
           | packetlost wrote:
           | I could see this maybe reducing latency, but wouldn't you
           | still be limited by the memory bus speed regardless of how
           | high you could clock the DDR?
        
             | wmf wrote:
             | The bus clock and memory clock are the same.
        
         | KingOfCoders wrote:
         | Not an expert, but Zen 5 desktop feels like it is being held
         | back by memory bandwidth. Several tests show there is no real
         | benefit in >6000 DRAMs.
        
           | Numerlor wrote:
           | Bandwidth is currently limited by the infinity fabric
           | implementation on consumer AMD CPUs, 6/8 core CPUs with s
           | single CCD top out bandwidth quite early and improvements
           | from higher clocks are minimal even from like 5600, assuming
           | timings are overclocked similarly and beyond basic xmp/expo
        
           | smolder wrote:
           | See my top level post for more on this. It's not that there
           | is _no_ benefit to higher frequency memory on AM5, but that
           | there is a penalty introduced above 6000 MT /s which isn't
           | easily outweighed by further raising the memory speed.
        
         | Numerlor wrote:
         | Granite ridge can currently do 8000-8400 when overclocked at a
         | 1:2 ratio of memory controller clock to memory clock, though
         | with some work needed to get it working.
         | 
         | The 9600 may be possible with DIMMs using the clock driver even
         | on granite ridge
        
         | throw0101a wrote:
         | > _It doesnt appear Zen5 can get anywhere close those speeds._
         | 
         | Looks like it can get to DDR5-8400:
         | 
         | > _Finally, we have some absolutely killer RAM. The G.SKILL
         | Trident Z5 RGB series is one of that vendor 's top brands, and
         | this is among the top models that it offers. Clocked at a
         | scorching 8400 MT/s with a CAS latency of just 40 cycles, this
         | is the fastest RAM we can reasonably recommend for Ryzen 9000.
         | It comes in the form of a pair of 24GB modules, and using it
         | with Zen 5 could be as easy as just flicking on that XMP
         | switch._
         | 
         | * https://hothardware.com/news/zen5-ddr5-memory-guide
         | 
         | Does that count as "anywhere close"?
        
         | qingcharles wrote:
         | I assume the 285K will be able run these at their full 9600?
        
       | tapper wrote:
       | I think Asgard is VCuller.
        
       | fecal_henge wrote:
       | I'd love to see their test fixture for binning the chips.
        
       | gryn wrote:
       | did they also make a compatible motherboard ? because I can't get
       | mine to go past 4800Mhz when my RAM is rated for 6400Mhz with AM5
       | CPU.
       | 
       | for those who hadn't done this for a while, PSA: motherboards
       | these days have a RAM compatibility list on their product page,
       | check it before overspending on RAM.
        
         | Numerlor wrote:
         | The motherboard QVLs aren't particularly useful, the higher
         | tier kits can often just not work as they're currently more
         | often than not limited by the CPU memory controller quality
         | instead of purely motherboard or RAM ICs.
         | 
         | Did you try 6200/6000 for the kit? 6400 is up there for speeds
         | that may not work on AM5 with synced controller and memory
         | clocks without tuning it yourself, or working at all. Or is
         | that 4 DIMMs
        
         | Szpadel wrote:
         | I had similar issue with my 3950x I had stability issues with
         | 3600MT, so I optimized clicks instead (I loaded XMP profile and
         | then changed clock to lower value before tightening clocks with
         | memtest runs in between) What people often don't realize that
         | dimm quality allows you to get lower absolute time before data
         | is available for system. So when you lower clocks, you don't
         | need to wait that many cycles for the data. In that case you
         | might not get that much bandwidth that you would have
         | originally, but you can get the same or similar latency also
         | changing order of dimms on board can somehow alter how low you
         | can get (I have 4 dimms and swapping 2 on the same channel
         | improved significantly clocks that I was able to achieve - no
         | idea why)
        
         | zalebz wrote:
         | Make sure you're on the latest BIOS as many improvements have
         | been made since early AM5.
         | 
         | Anecdata: I just bought a used AM5 mobo and threw in this
         | memory kit CMK64GX5M2B6400C32; hitting 6400 was as simple as
         | turning on XMP and that's it.
        
         | ourmandave wrote:
         | I haven't done this for a while, but every time I come back
         | around the new specs with even basic hardware blow the doors
         | off my old rig.
        
         | zamadatix wrote:
         | More than the specific list of which RAM is compatible check
         | the table of how many slots/GB is supported at which speed. 1x
         | 8 GB DIMM is a lot easier to drive than 4x 48 for example. Also
         | keep in mind a lot of it depends more on the CPU than the
         | motherboard itself, though both play a part, and the QVL should
         | be a "safe bet". Particularly if you're willing to throw a bit
         | of extra voltage at the RAM.
         | 
         | CUDIMs should help a bit with those scaling tables due to
         | having the clock redrivers, but we'll have to see to be certain
         | how much.
        
           | J_Shelby_J wrote:
           | And they're often not stable even with the given XMP
           | profiles. All of my XMP profiles throw errors and require
           | backing off speed by a few hundred hertz to be stable.
           | 
           | Worth though. Much cheaper way to get a few extra percentage
           | points than custom liquid cooling. And since every game where
           | you would care about max FPS is bound by single threaded
           | performance fast RAM is it.
        
           | wtallis wrote:
           | > 1x 8 GB DIMM is a lot easier to drive than 4x 48 for
           | example.
           | 
           | That's a bit of an exaggeration. What matters are DIMMs _per
           | channel_ , and ranks per DIMM. Consumer systems have at most
           | two memory slots per channel, so 2x 8GB modules installed
           | correctly is just two separate instances of one DIMM per
           | channel, and 4x48GB is two separate instances of two DIMMs
           | per channel, with each module being dual-rank.
           | 
           | The best configurations for overclocking are supposed to be
           | motherboards with only one memory slot per channel, so that
           | when operating with one DIMM per channel there are no empty
           | slots providing stubs of wiring that degrade signal
           | integrity. But very few motherboards restrict themselves like
           | this for the sake of memory overclocking.
        
             | Numerlor wrote:
             | > But very few motherboards restrict themselves like this
             | for the sake of memory overclocking.
             | 
             | Though I'd hope they'd finally start doing it considering
             | the per DIMM capacities DDR5 brings (32 GB, with 64 GB
             | planned), and most consumers really not going for
             | capacities that'd require 2 DPC (DIMM per channel).
             | 
             | 1 DPC should've been the default by now with the amount of
             | 1 DPC and 2 DPC boards swapped, as it's just making things
             | worse in the most common use case
        
               | zamadatix wrote:
               | A lot of consumers care more about either of total
               | capacity or the concept of "I can just double my cheap
               | RAM later" than care about ~10% differences in RAM clock
               | speed. The latter is for those that really know what
               | they're doing to eek out a couple more percentage points
               | in benchmarks or non-consumer use cases, the former
               | appeal to both budget users and prosumers alike (just not
               | OC enthusiasts).
               | 
               | From that angle I don't necessarily disagree with 4
               | channel boards being more common than 2 channel boards,
               | even though I personally lean more towards a 2 channel
               | board myself (well, depending how well CUDIMMS scale I
               | may change my opinion).
        
             | zamadatix wrote:
             | 4x 8 GB is still a lot easier to drive at high speed than
             | 4x 48 GB, but yes, one factor in the above comparison is
             | indeed the number of DIMMs per channel. Ranks per DIMM is
             | definitely a factor as well, though on large capacity DIMMs
             | that tends to be a one sided story. Another factor in the
             | rabbit hole is banks, tying it all back.
             | 
             | The other part of 2 DIMM boards is the trace lengths can be
             | that much shorter (they need to be the same length so fewer
             | slots means less max length to match to).
        
         | dannyw wrote:
         | Your issue is more with AMD CPUs having poor quality memory
         | controllers; not the motherboard.
        
         | tredre3 wrote:
         | > PSA: motherboards these days have a RAM compatibility list on
         | their product page, check it before overspending on RAM.
         | 
         | That's a valuable PSA, but FYI it's been that way since the
         | 80s. I've been bitten by compatibility issues at least once a
         | decade since the 90s myself, and the answer from forums or
         | support is always "did you check the compatibility table tho?".
        
       | AnotherGoodName wrote:
       | People should be much more sceptical than they are being here.
       | Setting the xmp profile of Hynix or Samsung memory chips is right
       | up there with formatting usb keys way over spec. Did you know
       | Hynix or Samsung already binned these themselves and set them to
       | a lower spec?
       | 
       | The number of performance memory chips I've had that had to be
       | downclocked from their xmp profile for stability is ridiculous.
       | It's gotten to the stage where I'd recommend only buying memory
       | from the first party suppliers (eg. only buy Samsung or Hynix
       | memory). The gaming companies like the above are simply taking
       | that memory and overwriting the xmp profile while adding some
       | flashy but useless heat spreaders.
        
         | wtallis wrote:
         | > Did you know Hynix or Samsung already binned these themselves
         | and set them to a lower spec?
         | 
         | Hynix, Samsung, and Micron bin the chips for what speed they
         | can operate at with a 1.1V supply. These enthusiast modules are
         | using chips binned for the speed they can hit with 1.4V. The
         | XMP/EXPO profiles don't come from Hynix, Samsung, or Micron.
        
         | 0xcde4c3db wrote:
         | Also, the vendors announcing these things so far are ones I've
         | literally never heard of before. I'd still be a bit skeptical,
         | but I think it would actually mean something if Kingston,
         | G.Skill, Corsair, or Teamgroup announced this product. As it
         | stands, I have no reason to think that I'll ever be able to
         | actually buy this product.
         | 
         | > flashy but useless heat spreaders
         | 
         | The funny thing about heat spreaders on SDRAM is that they
         | originated as a skeuomorph of RDRAM modules from the early
         | Pentium 4 days, but everyone's pretty much forgotten that by
         | now, so the market is essentially flooded with "retro" memory
         | for no obvious reason except "everybody else does it".
        
         | homebrewer wrote:
         | Stability problems might very well come from incorrect
         | voltages. Since XMP profiles do not contain settings for most
         | voltages, they're set by the motherboard firmware, and those
         | values are often too high. I use XMP/EXPO profiles as a
         | starting point, they're almost always terrible by themselves.
        
       | smolder wrote:
       | I am only hypothesizing here, but I do not expect these to be
       | useful on AMDs current AM5 platform due to the design of the
       | memory controller.
       | 
       | The reason is there is currently a drop off in memory subsystem
       | performance when you go above DDR5-6000 speeds on Ryzen 7x00 (and
       | AFAIK Ryzen 9x00), because above that, the memory controller
       | inside the chip can't run in lock-step with the memory frequency.
       | Much of the enthusiast memory out there that is capable of higher
       | speeds already, like say DDR5-7200, doesn't pair well with AMD
       | chips as a result, as in that case the memory controller is
       | forced to work at a 1:2 instead of a 1:1 ratio, introducing
       | latency into the memory subsystem that results in overall worse
       | performance.
       | 
       | On the other hand, if these CUDIMMs can hit high enough
       | frequencies (like 10k+ MT/s,) it's possible that the benefits
       | will outweigh the negative related to this quirk of the memory
       | controller. Until I see this tested or someone with more
       | expertise clarifies this point, it's hard to say. Perhaps
       | DDR5-9600 will result in better performance than the current
       | DDR5-6000 "sweet spot".
        
       ___________________________________________________________________
       (page generated 2024-09-18 23:02 UTC)