Live data from Hacker News

ECC Memory and AMD's Ryzen – A Deep Dive

hardwarecanucks.com

11–20 of 21 posts

Re: ECC Memory and AMD's Ryzen – A Deep Dive

#11
post #9

> Since we don't have our own particle accelerator to bombard the memory modules with in order to cause radiation-based errors I really want to see someone get some radioisotopes and place them next to both ECC and non-ECC RAM (while forcing reads and writes to the affected memory) to see what sort of soft errors / SEUs happen.

The folks at Los Alamos have done that one better and actually measured GPUs placed in neutron beamlines:

https://www.cs.utexas.edu/users/skeckler/pubs/SELSE_2014_Rel...

http://users.nccs.gov/~vazhkuda/hpca.pdf (section 6)

Re: ECC Memory and AMD's Ryzen – A Deep Dive

#12
post #10
post #7

Earlier quoted context omitted.

I think that just hangs the whole machine, which is no worse than what happens when the OS does not handle uncorrectable errors.

I think we would actually be in undefined behavior's territory. If that demon is kind the machine hangs, if not it could start sending and endless stream of gibberish down the SATA bus.

Other kinds of faults are handled just fine. There's a fault handler, a double fault handler for when that has a problem, and triple fault is a reset.

There's no reason a fault while in the ECC error handler shouldn't have the same progression.

Re: ECC Memory and AMD's Ryzen – A Deep Dive

#13
post #3

The conclusion of the article is mostly false at least for Linux: UE errors have no reasons to panic the machine in all cases, and by default under Linux the affected processes are simply killed. Of course, if this is kernel memory, then you will panic, but the probability of it being kernel memory is low (amount of kernel memory / total memory...). This has been signaled in the comments (not by me) but unfortunately…

What are the benefits for the average workstation user? What kinds of problems would I have on a non ECC development box?

I thought perhaps video editing and rendering would be a more likely area where ECC could be valuable to the non-scientific user. I have gone googling for examples of artifacting in videos caused by non-ECC ram errors, but I found nothing.

Re: ECC Memory and AMD's Ryzen – A Deep Dive

#14
post #11
post #9

> Since we don't have our own particle accelerator to bombard the memory modules with in order to cause radiation-based errors I really want to see someone get some radioisotopes and place them next to both ECC and non-ECC RAM (while forcing reads and writes to the affected memory) to see what sort of soft errors / SEUs happen.

The folks at Los Alamos have done that one better and actually measured GPUs placed in neutron beamlines: https://www.cs.utexas.edu/users/skeckler/pubs/SELSE_2014_Rel... http://users.nccs.gov/~vazhkuda/hpca.pdf (section 6)

Lovely!

Re: ECC Memory and AMD's Ryzen – A Deep Dive

#15
post #13
post #3

The conclusion of the article is mostly false at least for Linux: UE errors have no reasons to panic the machine in all cases, and by default under Linux the affected processes are simply killed. Of course, if this is kernel memory, then you will panic, but the probability of it being kernel memory is low (amount of kernel memory / total memory...). This has been signaled in the comments (not by me) but unfortunately…

What are the benefits for the average workstation user? What kinds of problems would I have on a non ECC development box? I thought perhaps video editing and rendering would be a more likely area where ECC could be valuable to the non-scientific user. I have gone googling for examples of artifacting in videos caused by non-ECC ram errors, but I found nothing.

The tangible benefits, in 2017, for the "average workstation user" (if such a thing even exists) are vanishingly slim.

The sole benefit is correcting random bitflips in memory. These bitflips don't occur often enough per byte of RAM in workstation environments to matter: It's far more likely you'll have an issue with corruption due to poorly developed software than due to EMI.

However if you're building a home NAS on commodity hardware, and you're concerned about things like data integrity, ECC is definitely preferred.

Re: ECC Memory and AMD's Ryzen – A Deep Dive

#16
post #15
post #13

Earlier quoted context omitted.

What are the benefits for the average workstation user? What kinds of problems would I have on a non ECC development box? I thought perhaps video editing and rendering would be a more likely area where ECC could be valuable to the non-scientific user. I have gone googling for examples of artifacting in videos caused by non-ECC ram errors, but I found nothing.

The tangible benefits, in 2017, for the "average workstation user" (if such a thing even exists) are vanishingly slim. The sole benefit is correcting random bitflips in memory. These bitflips don't occur often enough per byte of RAM in workstation environments to matter: It's far more likely you'll have an issue with corruption due to poorly developed software than due to EMI. However if you're building a home NAS on…

Let's say the workstation packs 64GB of RAM, and it's used for number-crunching tasks which include jobs that take as much RAM as they can get.

How often do you believe these random bitflips could happen in a year of continuous use?

Re: ECC Memory and AMD's Ryzen – A Deep Dive

#18
post #8
post #5

Earlier quoted context omitted.

The fun thing is that things like rowhammer can cause errors in unrelated memory.

At least ECC turns a RCE into a DoS, even if it's not the best situation.

Nah you just flip three bits at a time instead of two.

Re: ECC Memory and AMD's Ryzen – A Deep Dive

#19
post #15
post #13

Earlier quoted context omitted.

What are the benefits for the average workstation user? What kinds of problems would I have on a non ECC development box? I thought perhaps video editing and rendering would be a more likely area where ECC could be valuable to the non-scientific user. I have gone googling for examples of artifacting in videos caused by non-ECC ram errors, but I found nothing.

The tangible benefits, in 2017, for the "average workstation user" (if such a thing even exists) are vanishingly slim. The sole benefit is correcting random bitflips in memory. These bitflips don't occur often enough per byte of RAM in workstation environments to matter: It's far more likely you'll have an issue with corruption due to poorly developed software than due to EMI. However if you're building a home NAS on…

That's bullshit. You have no reason to care about data integrity in your NAS but not in your workstation. Plus "random" bitflips can have various causes, and except if you spend a weekend to a month memtesting your non-ECC ram you have no way to not know if you don't have a slightly defective chip. Also, if you wish to risk to trash your most important design files after a good afternoon of work, or miscompile a binary for extra fun, or maybe even an FPGA bitstream, well that's your problem and to each one their way to have fun, however on my side I rather not piment my life with that kind of crap.

The last thing you want if you are doing any kind of creative work is more or less random bitflips that happen very rarely but still more that lets say once in a year (YMMV). If your bitflips are too frequent you will soon notice and "fix" the problem (if you don't switch to ECC you actually fix nothing, but if you have a defective chip and switch to a good one at least you mitigate your issue)

For information the defect rate in consumer electronic is in the order of 1% (not specifically for RAM, I don't have any exact figure, but as a general order of magnitude figure it should be something like 1%). I know there are too much software bug here and there, but I don't want to add extra ultra-non-deterministic data destructing bugs just for fun.

Re: ECC Memory and AMD's Ryzen – A Deep Dive

#20
post #15

Earlier quoted context omitted.

The tangible benefits, in 2017, for the "average workstation user" (if such a thing even exists) are vanishingly slim. The sole benefit is correcting random bitflips in memory. These bitflips don't occur often enough per byte of RAM in workstation environments to matter: It's far more likely you'll have an issue with corruption due to poorly developed software than due to EMI. However if you're building a home NAS on…

Let's say the workstation packs 64GB of RAM, and it's used for number-crunching tasks which include jobs that take as much RAM as they can get. How often do you believe these random bitflips could happen in a year of continuous use?

It depends, with perfect components maybe as rare as one bitflip a year, or maybe even less. However you can have all the spectrum with slightly defective components. There are some rates that are really unfortunate because you don't even detect them with a few hours of memtest, yet when you use your WS for lets say a few weeks every so often you have a random extra non-deterministic fun crash, like an ICE that disappear when you relaunch your build.

Unless you have some funny notion of how you want to spend your time, you don't want to risk to fall in that situation...

Post reply on HN