[flagged]
JEDEC Extends DDR5 Memory Spec to 8800 MT/S, Adds Anti-Rowhammer Features
161–170 of 184 posts
Re: JEDEC Extends DDR5 Memory Spec to 8800 MT/S, Adds Anti-Rowhammer Features
#162[flagged]
Re: JEDEC Extends DDR5 Memory Spec to 8800 MT/S, Adds Anti-Rowhammer Features
#163[flagged]
Re: JEDEC Extends DDR5 Memory Spec to 8800 MT/S, Adds Anti-Rowhammer Features
#164[flagged]
Re: JEDEC Extends DDR5 Memory Spec to 8800 MT/S, Adds Anti-Rowhammer Features
#165[flagged]
Re: JEDEC Extends DDR5 Memory Spec to 8800 MT/S, Adds Anti-Rowhammer Features
#166Earlier quoted context omitted.
> Some gaming memory kits can do 10ns or less latency Source? My overclocked desktop RAM shows 45ns in benchmarks. I call bullshit on 4.5x faster RAM. Most people fight for an extra 5% latency reduction
That's probably 10 ns for the DRAM and 35 ns for the caches and memory controller.
Just to make sure I understand: you're saying that checking L1/L2/L3 takes around 35ns, and then the CPU accesses DRAM which takes 10ns? If that's so, how is L3 cache any faster than DRAM? Also, can you explain why the memory controller adds some latency?
Re: JEDEC Extends DDR5 Memory Spec to 8800 MT/S, Adds Anti-Rowhammer Features
#167Earlier quoted context omitted.
You mean memory fences? The big architecture (x86, ARM, RISC-V) all contain instructions for them.
I mean permanently disable all speculative execution on a specific core and reduce/disable all side-channels of the kind. If you're saying I can do through injection of fence instructions between every instruction, coupled with isolcpus... I might have a fun weekend coming playing with Intel Pin. But I'm guessing the performance hit might be worse than 'just' disabling speculative execution on a core - if it was poss…
Yep. Memory fences are a sniper rifle, EIEIO+ is a shotgun, and side channel attacks are a knife fight.
Re: JEDEC Extends DDR5 Memory Spec to 8800 MT/S, Adds Anti-Rowhammer Features
#168Earlier quoted context omitted.
That's probably 10 ns for the DRAM and 35 ns for the caches and memory controller.
Just to make sure I understand: you're saying that checking L1/L2/L3 takes around 35ns, and then the CPU accesses DRAM which takes 10ns? If that's so, how is L3 cache any faster than DRAM? Also, can you explain why the memory controller adds some latency?
An L3 hit only takes ~15 ns so that means another 15-20 ns is spent traversing the fabric and memory controller. I'm not sure what all is involved there but for Intel it has to go around the ring and for AMD it has to cross chiplets.
Re: JEDEC Extends DDR5 Memory Spec to 8800 MT/S, Adds Anti-Rowhammer Features
#169Earlier quoted context omitted.
How many cycles could this actually save? I would assume the latency to actually get data from DDR is only a small part of the whole round-trip in a L1 miss. Actual savings much smaller than 30%.
Most of the cost of an L3 miss comes after the miss itself, for most architectures I've seen. E.g., on Skylake an L3 hit is 80 cycles (~20ns) whereas a RAM access is 80 cycles plus 50 nanos (~70 nanos). See https://www.7-cpu.com/cpu/Skylake_X.html
From my rough knowledge of textbooks RAM access is usually in the hundreds of cycles. The napkin math makes more sense in that order of magnitude too! In any case it seems unlikely L3 has similar latency considering memory heirachy!
Interesting discussion though!
Re: JEDEC Extends DDR5 Memory Spec to 8800 MT/S, Adds Anti-Rowhammer Features
#170https://stefan.t8k2.com/rh/PRAC/index.html Chapter 16: "DDR5 Per Row Activation Counting (PRAC)". PRAC introduces two key mechanisms for comprehensive Rowhammer defenses: an Activation Counter for every DRAM row and a mechanism that triggers when an Activation Counter reaches a specific threshold. This allows the DRAM to pause the memory controller from issuing new commands, giving it time to refresh potential victim…
I'll bet good money that this gets turned into a timing attack soon - it's a prototypical address-dependent delay.