Live data from Hacker News

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

anandtech.com

71–80 of 184 posts

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

#71
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.

The way to do that would be with a chip & socket that has 4 independent memory channels (threadripper I think has eight now, but maybe used to have four?) and a many-layered motherboard that optimizes the routing and placement of each dimm slot, ideally with only 1 dimm slot per channel for maximum speed. The high end stuff with many memory channels generally isn't designed for pushing RAM clocks to gaming desktop speeds, though. You'd probably need to skip on ECC too or overclock and manually time some.

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

#72
post #52

Earlier quoted context omitted.

Things are bad, so make no attempt to better or even avoid worsening them?

Anything can be made to sound wrong or right if you get abstract and vague enough. We shouldn’t sacrifice something for nothing.

A considerable amount of effort goes into mitigating side channels precisely because it isn't for nothing.

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

#75

Earlier quoted context omitted.

Bring back EIEIO, like on Old Macs, but perhaps with a slightly expanded definition of what constitutes I/O: Enforce In-order Execution of I/O (EIEIO) is an assembly language instruction used on the PowerPC central processing unit (CPU) which prevents one memory or input/output (I/O) operation from starting until the previous memory or I/O operation completed. This instruction is needed ] as I/O controllers on the sy…

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 possible at all - or that the fence instructions might not be enough there? Haven't thought it through.

But it would be a fun question to ask the likes of Daniel Gruss...

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

#76

The article doesn't mention much about chip-to-controller distance or path length, presumably this suffers from the same issues we currently see where low power devices (and in some desktop configurations as well) can't really ever get those speeds unless the DRAM chips are near or on top of the CPU substrate. It's nearly impossible to do those numbers in modern mobile form factors, even CAMM is having a hard time ge…

Generally the highest speeds aren’t intended for low power devices. They’re targeted at applications where performance is the most important goal and the power tradeoffs are not an issue. Enthusiast motherboards and RAM kits can already exceed these speeds. Having official JEDEC timings just makes these speed a more universal target for long-term high end designs.

While that's true, It's also true that mobile devices tend to be a rather static configuration during their lifetime, and if you're going to have a fleet of those, having the best performance during that lifetime is a nice bonus. So I believe that form factor specific considerations are still a good value to write about.

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

#79

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)

Not even that; this just sets standard speed/latency values for memory modules without XMP. You can already exceed these numbers with XMP. PRAC would need handling in the memory controller, so that would require a CPU update if I understand correctly.

PRAC should happen automatically in the background when possible and when it really needs to stop the controller from accessing something while waiting for the bits to refresh it uses the already existing ALERTn signal.

https://stefan.t8k2.com/rh/PRAC/index.html

> Panopticon retrofits an existing signal in the DDR specification, called ALERTn, to effectively “trick” the memory controller to pause issuing new DDR commands. DRAM uses ALERTn to signal errors to the memory controller. Upon receiving this signal, the memory controller stops issuing new DRAM commands and instead re-issues the old memory access. By making use of ALERTn, Panopticon requires no modifications to any hardware other than DRAM itself.

(As I understand PRAC uses the same design as Panopticon for this part)

Post reply on HN