4 ms·

Actually me too. I did write a program a while back to investigate the rumors about this though. Spoiler alert: Doesn't really happen. (https://github.com/s9w/M

by s9w 6y ago

Actually me too. I did write a program a while back to investigate the rumors about this though. Spoiler alert: Doesn't really happen. (https://github.com/s9w/MCC https://github.com/s9w/MCC)

faeyanpiraat 6y ago
I’m mildly disappointed aswell.
bArray 6y ago
Well, I'm also happy this doesn't happen! RAM is designed to be stable! If you have the resources, have you considered getting a source of radiation and putting it by the RAM? In a plane for example, background radiation can be 30x or so. It might also reduce the time to see a flip... Other considerations: 1. The act of checking the RAM (I believe) refreshes the memory cells. 2. I suspect the act of regularly changing the RAM bits to have an effect on the data stored. I think when the bit transitions from a 0 to 1 or vice versa, some inconvenient piece of solar radiation could bias it to a different state. That said, you would have to separate that from accidental row-hammer events. 3. You would think that higher temperature RAM was more likely to bit flip (the Scientific term is more wiggly electrons). 4. RAM clock speed. The higher it is, the less time it has to stabilize at the transistor level. 5. Memory cell size. The smaller it is, the more likely it will be affected. There are probably tonnes of variables, but these are the ones I can think of for now.
- s9w 6y ago
  That's actually a couple of interesting ideas. I don't think however that 1) is completely correct? As far as I remember from my classes, RAMs are refreshed all the time on very small time scales exactly because they're volatile. Therefore a manual read shouldn't influence things. Temperatures and clock speed would be very interesting. Not sure I want to even google for radiation sources though :D
  - formerly_proven 6y ago
    DRAM reads are destructive, so reading a row always refreshes it. On the other hand, every row is refreshed every ~64 ms. (This is governed by tREFI, the interval between successive rows being refreshed. For example a module with 8K rows would require a tREFI of 64 ms / 8K = 7.8 us = 12480 clocks (7.8 us / (1600 MHz)^-1)). Increasing tREFI is one of those things people do to improve memory performance, because less time spent refreshing means more time available for useful work. Some memory chips can use very high values, which would be equivalent to ~200 ms, others corrupt data consistently much before that. So while rows are refreshed very often, a specific row is only refreshed ten times per second or so.
    - s9w 6y ago
      Interesting, thanks for the numbers. That would mean that it would probably be feasible to significantly influence the mean refresh times.
apankrat 6y ago
Bit flips in RAM happen often enough to be an issue. I make a desktop program with a sizeable installation base and it uses a form paged on-disk storage for larger data sets. The code has a fair amount of asserts in it and one specific assert would keep failing in a very tiny percentage of the cases. I kept reviewing the code and scratching my head before finally adding some extra logging for this case. Lo and behold, in all failed cases an argument passed to a function had one of the bits set for no apparent reason. I.e. the offsets of pages in the cache would be: 00000000000000 ... 00000000100000 ... 00000000200000 ... 00000000300000 ... But the args would come in as 80000000100000 00040000200000 01000000300000 ... Followed up with the people who reported these, asked to run an overnight RAM test and ALL of them found issues with their RAM. That was quite an eye-opener.
- Someone 6y ago
  You weren’t explicitly saying it, but some might infer it, so I think it’s worth mentioning that bit flips in RAM aren’t necessarily radiation-induced. Some other causes are heat and aging (both increase capacitor leakage, and DRAM cells are tiny capacitors), or lack of robustness in refresh logic.
  - quercusa 6y ago
    Another cause, at least in the old days, was bad board design, in which badly-placed traces could induce currents in other traces. Of course this only happened two+ hours into the test.
- s9w 6y ago
  I remember a blog post by Riot (league of legends developer) also about this happening. But I couldn't find it again when I was searching for it. I can't imagine the havoc that regular bit flips must cause.
- tyingq 6y ago
  One of the more interesting ways to test this is to register a one character typo of a very popular domain where the typo is one bit off. Like, say, dacebook.com or facebooo.com Spin up a web server, and you'll get traffic, but typically only one of the requests from a specific client.
dnautics 6y ago
but did you put a radiation source next to your non-ecc ram?

by s9w 6y ago

Actually me too. I did write a program a while back to investigate the rumors about this though. Spoiler alert: Doesn't really happen. (https://github.com/s9w/MCC https://github.com/s9w/MCC)

faeyanpiraat 6y ago

I’m mildly disappointed aswell.

bArray 6y ago

Well, I'm also happy this doesn't happen! RAM is designed to be stable! If you have the resources, have you considered getting a source of radiation and putting it by the RAM? In a plane for example, background radiation can be 30x or so. It might also reduce the time to see a flip... Other considerations: 1. The act of checking the RAM (I believe) refreshes the memory cells. 2. I suspect the act of regularly changing the RAM bits to have an effect on the data stored. I think when the bit transitions from a 0 to 1 or vice versa, some inconvenient piece of solar radiation could bias it to a different state. That said, you would have to separate that from accidental row-hammer events. 3. You would think that higher temperature RAM was more likely to bit flip (the Scientific term is more wiggly electrons). 4. RAM clock speed. The higher it is, the less time it has to stabilize at the transistor level. 5. Memory cell size. The smaller it is, the more likely it will be affected. There are probably tonnes of variables, but these are the ones I can think of for now.

s9w 6y ago
That's actually a couple of interesting ideas. I don't think however that 1) is completely correct? As far as I remember from my classes, RAMs are refreshed all the time on very small time scales exactly because they're volatile. Therefore a manual read shouldn't influence things. Temperatures and clock speed would be very interesting. Not sure I want to even google for radiation sources though :D
- formerly_proven 6y ago
  DRAM reads are destructive, so reading a row always refreshes it. On the other hand, every row is refreshed every ~64 ms. (This is governed by tREFI, the interval between successive rows being refreshed. For example a module with 8K rows would require a tREFI of 64 ms / 8K = 7.8 us = 12480 clocks (7.8 us / (1600 MHz)^-1)). Increasing tREFI is one of those things people do to improve memory performance, because less time spent refreshing means more time available for useful work. Some memory chips can use very high values, which would be equivalent to ~200 ms, others corrupt data consistently much before that. So while rows are refreshed very often, a specific row is only refreshed ten times per second or so.
  - s9w 6y ago
    Interesting, thanks for the numbers. That would mean that it would probably be feasible to significantly influence the mean refresh times.

apankrat 6y ago

Bit flips in RAM happen often enough to be an issue. I make a desktop program with a sizeable installation base and it uses a form paged on-disk storage for larger data sets. The code has a fair amount of asserts in it and one specific assert would keep failing in a very tiny percentage of the cases. I kept reviewing the code and scratching my head before finally adding some extra logging for this case. Lo and behold, in all failed cases an argument passed to a function had one of the bits set for no apparent reason. I.e. the offsets of pages in the cache would be: 00000000000000 ... 00000000100000 ... 00000000200000 ... 00000000300000 ... But the args would come in as 80000000100000 00040000200000 01000000300000 ... Followed up with the people who reported these, asked to run an overnight RAM test and ALL of them found issues with their RAM. That was quite an eye-opener.

Someone 6y ago
You weren’t explicitly saying it, but some might infer it, so I think it’s worth mentioning that bit flips in RAM aren’t necessarily radiation-induced. Some other causes are heat and aging (both increase capacitor leakage, and DRAM cells are tiny capacitors), or lack of robustness in refresh logic.
- quercusa 6y ago
  Another cause, at least in the old days, was bad board design, in which badly-placed traces could induce currents in other traces. Of course this only happened two+ hours into the test.
s9w 6y ago
I remember a blog post by Riot (league of legends developer) also about this happening. But I couldn't find it again when I was searching for it. I can't imagine the havoc that regular bit flips must cause.
tyingq 6y ago
One of the more interesting ways to test this is to register a one character typo of a very popular domain where the typo is one bit off. Like, say, dacebook.com or facebooo.com Spin up a web server, and you'll get traffic, but typically only one of the requests from a specific client.

dnautics 6y ago

but did you put a radiation source next to your non-ecc ram?