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.

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.

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.

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.

it has to be a one-bit-error byte change in particular.

https://media.blackhat.com/bh-us-11/Dinaburg/BH_US_11_Dinabu...

I read a blog article years back by a game author who inserted CPU/RAM/Math sanity checks into the code (I forget what the reason he did this for was), and he was suprised with how often it detected hardware errors in customer's PCs.

Wish I could find the article again, I forget the details but it was a fun read.

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.

Were all the machines which reported that in the same building (your software could been used in house). If so, better check for radiation levels, for health risks; I have never seen a RAM test fail actually (apart from a completely broken chip)

If you've got a system where you can tweak the ram timings and/or voltages (most desktops will let you do at least some of this), it's pretty easy to induce failures, if you haven't run into bad ram naturally.

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).

As mentioned below it can deteriorate over time. A while ago I had a RAM stick fail. I noticed because GCC started segfaulting randomly and I haven't upgraded GCC recently. Sure enough a memtest revealed the fault. I think it didn't have enough cooling.

I only purchased RAM with heatsinks since then, and I didn't have such problems anymore (also my latest case has much better airflow)

I unplugged the wrong power cable once, and thereafter the RAID controller on that machine would report degradation after the system was running for a while. Finally ran a RAM error check, one bit in most of a stick was flipped. The last stick. So once the machine was all spooled up for a while, I’d get errors.

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.

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.

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

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.

Interesting, thanks for the numbers. That would mean that it would probably be feasible to significantly influence the mean refresh times.

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

I’m mildly disappointed aswell.