DDR5 Is Coming: First 64GB DDR5-4800 Modules from SK Hynix • Hacker News Board

Re: DDR5 Is Coming: First 64GB DDR5-4800 Modules from SK Hynix

#201

Post by shaklee3 » Wed, Oct 07, 2020, 4:43 AM UTC

lucb1e wrote: post #143

DCKing wrote: post #76

One thing I'd like to understand better about DDR5 is how well the built-in ECC is going to work to improve reliability. DDR5 comes with "chip level ECC" [1] of which the main purpose is to be able to better sell highly complicated memory chips with minor defects. But as a consequence as I understand, it will allow for the correction of single bit memory flips. With regular DDR4 or previous generations, you don't get…

I actually tried really hard to get RAM to corrupt a bit for a school project and didn't manage a single bit flip. How often have you actually heard of data corruption due to non-ECC memory? Either yourself, any degree of 'friend of a friend', or perhaps a study that looked into the matter with more success than I had. I don't mean a newspaper story because exceptional cases are reported because they're rare exceptio…

It's happened to me on a GPU. I had ecc disabled for a speed increase, and got a reproducible bit error.

Re: DDR5 Is Coming: First 64GB DDR5-4800 Modules from SK Hynix

#202

Post by josmala » Wed, Oct 07, 2020, 4:53 AM UTC

pedrocr wrote: post #173

Taniwha wrote: post #169

Earlier quoted context omitted.

Sort of - it allows them to build lots of different sorts of systems - many CPU chiplets and a mem controller, 1 CPU and a mem controller etc etc all from the same basic components - Intel have to spin a new chip for each SKU, AMD can build different SKUs by packaging stuff differently - it gives them a lot more flexibility and means they can spin out new stuff to fit a new market segment much more quickly

I know that motivation but I'm more curious about the hardware architecture angle. Integrating the memory controller in the CPU was supposedly a big gain at the time. Now it's in a different chip and multi-socket motherboards already have to traverse the board to access RAM attached to another chip. Are the interconnects better now and so going back to a single northbridge is workable? Would it simplify the topology…

On package interconnection latency and power is way lower than going off package, AMD also doubled the L3 cache size to compensate for increased memory latency. The issue of putting too much IO in single die is that perimeter of die/package needs to fit all the IO traces on substrate/motherboard, which means more layers and more costs. Everything is just a performance/cost/power trade off. But I would say that off package controllers dealing with multiple CPU chips are probably less viable now than they were before current core count increase.It's because synchronization traffic would require insanely large busses to those controllers, if you wanted to have lots of sockets, and then you would need a lot more pins to those. On the other hand if you had those on package you would get a lot more bandwidth at much lower power and latency, which is what AMD has done.

Re: DDR5 Is Coming: First 64GB DDR5-4800 Modules from SK Hynix

#203

Post by paulie_a » Wed, Oct 07, 2020, 6:10 AM UTC

lucb1e wrote: post #143

DCKing wrote: post #76

One thing I'd like to understand better about DDR5 is how well the built-in ECC is going to work to improve reliability. DDR5 comes with "chip level ECC" [1] of which the main purpose is to be able to better sell highly complicated memory chips with minor defects. But as a consequence as I understand, it will allow for the correction of single bit memory flips. With regular DDR4 or previous generations, you don't get…

I actually tried really hard to get RAM to corrupt a bit for a school project and didn't manage a single bit flip. How often have you actually heard of data corruption due to non-ECC memory? Either yourself, any degree of 'friend of a friend', or perhaps a study that looked into the matter with more success than I had. I don't mean a newspaper story because exceptional cases are reported because they're rare exceptio…

There was a great defcon talk about this. Basically using unicode and registering domain names with a bit flip resulted in results. Like email at Microsoft and some other major companies.

I think the title was dns squatting but can't find it at the moment

Re: DDR5 Is Coming: First 64GB DDR5-4800 Modules from SK Hynix

#204

Post by ficklepickle » Wed, Oct 07, 2020, 7:37 AM UTC

lucb1e wrote: post #143

DCKing wrote: post #76

One thing I'd like to understand better about DDR5 is how well the built-in ECC is going to work to improve reliability. DDR5 comes with "chip level ECC" [1] of which the main purpose is to be able to better sell highly complicated memory chips with minor defects. But as a consequence as I understand, it will allow for the correction of single bit memory flips. With regular DDR4 or previous generations, you don't get…

I actually tried really hard to get RAM to corrupt a bit for a school project and didn't manage a single bit flip. How often have you actually heard of data corruption due to non-ECC memory? Either yourself, any degree of 'friend of a friend', or perhaps a study that looked into the matter with more success than I had. I don't mean a newspaper story because exceptional cases are reported because they're rare exceptio…

I've experienced errors that likely propagated through memory errors.

I have a ZFS/NFS server on a 2012 i7 with 4gb RAM. I use it primarily to store various torrents (up to ~250GB each).

I have had my torrent client find single-chunk errors in a couple of torrents I was seeding (twice over a few TB worth of torrents). I recall reading ZFS filesystem over NFS is particularly prone to this. I did some worried searching and remember finding it was likely caused by memory errors being persisted to disk, but I don't have any links handy anymore.

I likely would not have noticed the corruption if the torrent client hadn't alerted me.

Re: DDR5 Is Coming: First 64GB DDR5-4800 Modules from SK Hynix

#205

Post by imtringued » Wed, Oct 07, 2020, 8:04 AM UTC

melling wrote: post #17

nullifidian wrote: post #9

Earlier quoted context omitted.

Load times? I doubt it. Load times are more about cpu and nvme.

However, all those people who complained that the Atom editor took too much memory are about to experience a new world when they buy their next computer. I used Emacs back when people joked “Eight Megs and Constantly Swapping”

To be fair. Electron bloat doesn't grow with application size. Only incompetence does. By using electron you are basically forcing your application to need around 200-300MB of RAM no matter how trivial it is, but that's all there is to it. Poor application performance has more to do with bad application development. Nothing prevents you from e.g. building Atom in a way that lets you view files bigger than 2MB with good performance or building a Slack client that doesn't leak memory. I can run lots of tabs in Firefox with good performance but if each tab was using its own browser instance I would run out of memory very quickly.

Re: DDR5 Is Coming: First 64GB DDR5-4800 Modules from SK Hynix

#206

Post by norenh » Wed, Oct 07, 2020, 12:39 PM UTC

paulie_a wrote: post #203

lucb1e wrote: post #143

Earlier quoted context omitted.

I actually tried really hard to get RAM to corrupt a bit for a school project and didn't manage a single bit flip. How often have you actually heard of data corruption due to non-ECC memory? Either yourself, any degree of 'friend of a friend', or perhaps a study that looked into the matter with more success than I had. I don't mean a newspaper story because exceptional cases are reported because they're rare exceptio…

There was a great defcon talk about this. Basically using unicode and registering domain names with a bit flip resulted in results. Like email at Microsoft and some other major companies. I think the title was dns squatting but can't find it at the moment

Bitsquatting? https://www.youtube.com/watch?v=9WcHsT97suU

Re: DDR5 Is Coming: First 64GB DDR5-4800 Modules from SK Hynix

#207

Post by SketchySeaBeast » Wed, Oct 07, 2020, 1:18 PM UTC

josmala wrote: post #199

SketchySeaBeast wrote: post #27

Earlier quoted context omitted.

What did you move from and then to? As near as I can tell IPC haven't increased that much in the last little bit. Or was your CPU pretty old?

I thought so also, but decade of small improvements do accumulate to a large number. Something like 20% improvement 4 times would be doubling the IPC, but single threaded compilation is where I got more than that. The after purchase testing was even better than expected. i7 920 compiled a specific compilation unit in 14 seconds. 3900x in 3.5 seconds. And that was before any tuning, I had done some bios tuning for i7…

The i7 920 is a dozen years old (2008). No explanation required. I was thinking there wasn't much of an IPC increase over the last half dozen years or so, but there's absolutely been one over that long. Though really it's funny how little it's still increased - in 1996 we were just getting Pentiums at 150 MHz, and I don't think anyone would argue those are anywhere near comparable.

Re: DDR5 Is Coming: First 64GB DDR5-4800 Modules from SK Hynix

#208

Post by paulie_a » Wed, Oct 07, 2020, 2:48 PM UTC

norenh wrote: post #206

paulie_a wrote: post #203

Earlier quoted context omitted.

There was a great defcon talk about this. Basically using unicode and registering domain names with a bit flip resulted in results. Like email at Microsoft and some other major companies. I think the title was dns squatting but can't find it at the moment

Bitsquatting? https://www.youtube.com/watch?v=9WcHsT97suU

That's the one, thanks for finding it. It really is fascinating

Re: DDR5 Is Coming: First 64GB DDR5-4800 Modules from SK Hynix

#209

Post by lucb1e » Wed, Oct 07, 2020, 10:25 PM UTC

deegles wrote: post #146

lucb1e wrote: post #143

Earlier quoted context omitted.

I actually tried really hard to get RAM to corrupt a bit for a school project and didn't manage a single bit flip. How often have you actually heard of data corruption due to non-ECC memory? Either yourself, any degree of 'friend of a friend', or perhaps a study that looked into the matter with more success than I had. I don't mean a newspaper story because exceptional cases are reported because they're rare exceptio…

Bunch of links to papers here: https://stackoverflow.com/questions/2580933/cosmic-rays-what... e.g. "2009 Google's paper "DRAM Errors in the Wild: A Large-Scale Field Study" says that there can be up to 25000-75000 one-bit FIT per Mbit (failures in time per billion hours), which is equal to 1 - 5 bit errors per hour for 8GB of RAM after my calculations. Paper says the same: "mean correctable error rates of 2000–6000…

> 1 - 5 bit errors per hour for 8GB of RAM after my calculations

That is way off from what I'm seeing. When launching Factorio I use 90% of my 8GB RAM and never once have I noticed data corruption, and I could tell you how many hours I've played but that would be embarrassing.

The test I did in school with heated-up RAM (the internet said that's when flips should occur more often) also wrote many many gigabytes without a single failure.

Not sure what hardware or temperatures that source is running but it's not DDR3/DDR4 at heats below hairdryer melting temperature because that's where I had to stop the experiment with zero failures.

Re: DDR5 Is Coming: First 64GB DDR5-4800 Modules from SK Hynix

#210

Post by lucb1e » Wed, Oct 07, 2020, 10:31 PM UTC

DCKing wrote: post #152

lucb1e wrote: post #143

Earlier quoted context omitted.

I actually tried really hard to get RAM to corrupt a bit for a school project and didn't manage a single bit flip. How often have you actually heard of data corruption due to non-ECC memory? Either yourself, any degree of 'friend of a friend', or perhaps a study that looked into the matter with more success than I had. I don't mean a newspaper story because exceptional cases are reported because they're rare exceptio…

I've seen bit flips reported in edac utils on a system with ECC memory. People routinely try to induce memory errors by overclocking their memory (to verify ECC is working). The triggering of bit flips is the very foundation of the Rowhammer attack (yes, I know Rowhammer can circumvent ECC with advanced techniques). Error correcting codes are used in networking environments, CPU caches, hard drives, anywhere but main…

If ECC is supposed to be a security measure then I can see the point, but aside from intentional flipping (by an attacker), a blanket statement like "it clearly isn't [an edge case] anymore" doesn't strike me as true. For it being a security measure, though, shouldn't it compute a much stronger checksum than one or two bits like ECC usually does?