Here I was hoping this was something about repurposing RAM as an actual geiger counter by measuring radiation-induced bit flips.
https://news.ycombinator.com/item?id=3179852
> So, my mom is a former Maxwell employee who now does her own defense contracting, and makes this same type of part.
> As I understand it, when there is a nuclear event, it generates x-rays followed by the EMP. The goal is to have warheads in flight to be able to continue to their target, so the strategy is to employ an NED. When an event is detected, the warhead shuts down its electronics for the duration of the EMP, and then powers back up.
> With her NED, she uses an ASIC for detection. I might get some details wrong, but the ASIC has a physical array in it, and the x-rays flip bits in the array. When enough bits get flipped, one can infer a nuclear event. Because it is an ASIC it is really small, which has important advantages for space-born avionics.
But yes, there always is an efficiency, precision and identification tradeoff.
For folks who might be interested in more details on this: The _cross section_ allows you to quantify the frequency of a specific event occurring in your chip when bombarded by a specific particle (or class of particles). For example, in a case of an SRAM, you might want to calculate the cross-section for bit flips due to 24-GeV protons. The result that you get will be in units of cm^2; you can also interpret it as the physical surface area of the chip, multiplied by the probability (0..1) that any 1 particle passing through will trigger an event. Let's say you measure a cross section of 0.01 mm^2. Then if you expose that component to a flux of 10^3 particles/cm^2/sec, you will get an average of 1 event every 10 seconds.
The cross-section is only valid for one combination of the (event type, particle, energy) tuple. But often in dosimetry, errors on the order of 20% are acceptable, so we can "abuse" the results a bit. Within one manufacturing lot of chips, the cross-sections should be reasonably consistent. Typically you would estimate the mean and variance by measuring a few samples from the lot.
Then, to accurately measure a radiation field using these findings, you would generally need to measure the flux of every particle-energy combination separately. This is impractical, and for SEE* concerns we generally get away with distinguishing thermal neutrons and high-energy hadrons (which are separated by several orders of magnitude in energy). For this, it is sufficient to have 2 types of SRAM where each has a dominant cross-section for one of the particle classes of interest.
To measure the type of radiation that causes long-term gradual damage (TID) such as X-ray and gamma rays, you would use a different principle of measurement altogether (RadFET, P-i-N diode, floating-gate dosimeter...)
Radiation measurement can be fun!
[*] single-event effects, including bit flips and latch-ups
Apparently it works reasonably well.
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.
Temperatures and clock speed would be very interesting. Not sure I want to even google for radiation sources though :D
So while rows are refreshed very often, a specific row is only refreshed ten times per second or so.
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 ...
80000000100000
00040000200000
01000000300000
...
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.
https://media.blackhat.com/bh-us-11/Dinaburg/BH_US_11_Dinabu...
I only purchased RAM with heatsinks since then, and I didn't have such problems anymore (also my latest case has much better airflow)
This is also how I learned 3ware was using RAM instead of its own memory. What is he point of hardware RAID if main memory can screw it up?
I have also heard of people swapping hardware on a defective machine only to learn that the power supply was bad, sending noise or brown power to the system. Swap in a new power supply and the components start to behave themselves.
I've run enough systems with ECC ram to say the vast majority of ram works and will continue to work, but over time, a small amount will fail, again the vast majority is a single bit in the whole chip, but some will do multiple bits near each other (uncorrectable ecc error usually halts the system), or man single bit errors all over (many machine check errors per second makes the system go so slow, halting would be better).
Wish I could find the article again, I forget the details but it was a fun read.