Live data from Hacker News

JEDEC Extends DDR5 Memory Spec to 8800 MT/S, Adds Anti-Rowhammer Features

anandtech.com

11–20 of 184 posts

Re: JEDEC Extends DDR5 Memory Spec to 8800 MT/S, Adds Anti-Rowhammer Features

#11

I'd like to see the spec tackle latency with a "send then confirm" approach. Ie. The RAM can reply to a read request with data, then a couple of clock cycles later it can confirm (via a flag) that the data it originally sent was correct. This is helpful because it means the timing can be tightened to the typical access times, rather than the worst case access time (eg. the slowest preamp on the highest capacitance me…

And potentially opens a whole new family of side channels.

Re: JEDEC Extends DDR5 Memory Spec to 8800 MT/S, Adds Anti-Rowhammer Features

#12

I'm a bit confused, DDR5 products are already out - as are CPUs and motherboards that support them. How can this change happen retroactively? Would motherboard manufacturers just need to update the BIOS to enable new XMP configurations? (For when this new, higher transfer rate RAM becomes available)

The spec is just a bunch of numbers which are already configurable and motherboards can already be set at much higher frequencies.

It doesn't mean that any particular combination of CPU/motherboard/RAM will work.

Re: JEDEC Extends DDR5 Memory Spec to 8800 MT/S, Adds Anti-Rowhammer Features

#13

I'm a bit confused, DDR5 products are already out - as are CPUs and motherboards that support them. How can this change happen retroactively? Would motherboard manufacturers just need to update the BIOS to enable new XMP configurations? (For when this new, higher transfer rate RAM becomes available)

It doesn't. If you buy A DDR5-6400 DIMM it doesn't get updated to 8800. It will stay at 6400. This just means that manufacturers will be able to brand their tested DDR5 DIMMs as supporting 8800. You still need a CPU and Mainboard that has been validated at those speeds. You're going to need a 8700G if you actually want to hit those speeds by the way.

Re: JEDEC Extends DDR5 Memory Spec to 8800 MT/S, Adds Anti-Rowhammer Features

#14
post #5

Earlier quoted context omitted.

HBM is slower than DDR per pin, the speed gain is from a hugely parallel bus. Parallel means latency if you have non "embarrassingly parallelizable" tasks?

The smallest transfer done from memory is a single cache line, which on most desktop machines is 64 bytes, or 512 bits. You could imagine a memory bus that was 512 bits wide and transferred a cache line per clock, and this would improve latency when compared to a serial bus with higher clock speed. HBM doesn't do that, though, instead every HBM3 module has 16 individual 64-bit channels, with 8n prefetch (that is, whe…

DDR5 has 2 independent 32-bit lanes. Multiple transfers are required for 64 bytes.

Re: JEDEC Extends DDR5 Memory Spec to 8800 MT/S, Adds Anti-Rowhammer Features

#15

> Unfortunately, the laws of physics driving DRAM cells have not improved much over the last couple of years (or decades, for that matter), so memory chips still must operate with similar absolute latencies, driving up the relative CAS latency. In this case 14ns remains the gold standard, with CAS latencies at the new speeds being set to hold absolute latencies around that mark. Some gaming memory kits can do 10ns or…

As others have said, there is nothing low latency about HBM.

Renesas did have a special Low Latency HBM thing at one point, but I don't think it ever saw the light of day.

Re: JEDEC Extends DDR5 Memory Spec to 8800 MT/S, Adds Anti-Rowhammer Features

#16
post #9

I'm always a fan of bigger numbers, but I wish more time/money/whatever was put into letting DDR5 run at those XMP/EXPO speeds when using 4 DIMMs.

How do you expect that to happen? By sharing memory channels you are no longer using a point to point connection and are now prone to reflections in the PCB traces where you have split the signal. There is no "money" that can be put into this, that won't also improve the performance of the single DIMM per channel setup disproportionately. I don't even understand what your point is. Quad channel support would be a much better idea since it doubles your memory bandwidth, while remaining a point to point connection, but you're going to complain that you can't add eight DIMMs then.

Re: JEDEC Extends DDR5 Memory Spec to 8800 MT/S, Adds Anti-Rowhammer Features

#17

Earlier quoted context omitted.

The smallest transfer done from memory is a single cache line, which on most desktop machines is 64 bytes, or 512 bits. You could imagine a memory bus that was 512 bits wide and transferred a cache line per clock, and this would improve latency when compared to a serial bus with higher clock speed. HBM doesn't do that, though, instead every HBM3 module has 16 individual 64-bit channels, with 8n prefetch (that is, whe…

DDR5 has 2 independent 32-bit lanes. Multiple transfers are required for 64 bytes.

DDR5 has a 16n prefetch, so a single transfer from a 32-wide channel moves 64 bytes.

Re: JEDEC Extends DDR5 Memory Spec to 8800 MT/S, Adds Anti-Rowhammer Features

#18

I'd like to see the spec tackle latency with a "send then confirm" approach. Ie. The RAM can reply to a read request with data, then a couple of clock cycles later it can confirm (via a flag) that the data it originally sent was correct. This is helpful because it means the timing can be tightened to the typical access times, rather than the worst case access time (eg. the slowest preamp on the highest capacitance me…

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%.

Re: JEDEC Extends DDR5 Memory Spec to 8800 MT/S, Adds Anti-Rowhammer Features

#19

I'd like to see the spec tackle latency with a "send then confirm" approach. Ie. The RAM can reply to a read request with data, then a couple of clock cycles later it can confirm (via a flag) that the data it originally sent was correct. This is helpful because it means the timing can be tightened to the typical access times, rather than the worst case access time (eg. the slowest preamp on the highest capacitance me…

And potentially opens a whole new family of side channels.

I wish we could mix 'I don't care about side channels, use them all' with 'I'm paranoid about side channels, plug them all' on the same machine. Disable speculative execution on one core, no frequency adjustment, no prefetching, sr-io/pcie-bypass some devices... E-cores but for the side-channel-paranoid (in a good way).

Re: JEDEC Extends DDR5 Memory Spec to 8800 MT/S, Adds Anti-Rowhammer Features

#20

I'd like to see the spec tackle latency with a "send then confirm" approach. Ie. The RAM can reply to a read request with data, then a couple of clock cycles later it can confirm (via a flag) that the data it originally sent was correct. This is helpful because it means the timing can be tightened to the typical access times, rather than the worst case access time (eg. the slowest preamp on the highest capacitance me…

And potentially opens a whole new family of side channels.

I mean nobody really believes there aren’t already countless side channels in existing hardware, right? No reason to give up performance for nothing.
Post reply on HN