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…
JEDEC Extends DDR5 Memory Spec to 8800 MT/S, Adds Anti-Rowhammer Features
11–20 of 184 posts
Re: JEDEC Extends DDR5 Memory Spec to 8800 MT/S, Adds Anti-Rowhammer Features
#12I'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 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
#13I'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)
Re: JEDEC Extends DDR5 Memory Spec to 8800 MT/S, Adds Anti-Rowhammer Features
#14Earlier 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…
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…
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
#16I'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.
Re: JEDEC Extends DDR5 Memory Spec to 8800 MT/S, Adds Anti-Rowhammer Features
#17Earlier 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.
Re: JEDEC Extends DDR5 Memory Spec to 8800 MT/S, Adds Anti-Rowhammer Features
#18I'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…
Re: JEDEC Extends DDR5 Memory Spec to 8800 MT/S, Adds Anti-Rowhammer Features
#19I'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
#20I'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.