71–80 of 96 posts
On the subject of bit flips, I am able to detect these in the client to server UDP packets in my game. With specific logging enabled I would see an error about once per minute while receiving about 15,000 of one type of packet per second. I was able to estimate about 1/1,000,000 packets contained a single flipped bit.
As the article points out, using collected client data is problematic, because some errors will often be undetectable, as in numeric data. And in general, you would have to control for bit flips somehow caused by software. I wonder whether a SETI approach would be useful here. Allocate, say, 1MB of memory. Fill it with some known bit pattern. Periodically check the memory and look for discrepancies. Do this once an h…
I've few years ago hear, US gov't created app, which periodically checked for random light flashes on camera sensor of smartphone, and send info to cloud, to use them as large distributed network for detecting of illegal nukes. (btw, Soviet and Russians really love to collect such weird facts). Idea looks very realistic, except that it will drain battery, and could also be used as surveillance tool, so I have not see…
At least at one point they had satellites deployed for this purpose. The phenomena they used to determine whether a detonation had taken place was the characteristic 'double flash'. You can read some more about this here: https://en.wikipedia.org/wiki/Vela_incident
They don't need to resort to such clandestine measures as infiltrating people's smartphones for this purpose. A nuclear blast was a pretty difficult thing to hide even 40 years ago.
"Bitsquatting is a form of cybersquatting which relies on bit-flip errors that occur during the process of making a DNS request. These bit-flips may occur due to factors such as faulty hardware or cosmic rays. When such an error occurs, the user requesting the domain may be directed to a website registered under a domain name similar to a legitimate domain, except with one bit flipped in their respective binary repre…
So I had a look into the paper, because I was curious how they would differentiate typos from bitflips ... turns out they don't. Bummer. There's only some assumptions made here and there without any further explanation. It could even be the result of bad OCR or whatever weird stuff people do on the internet ...
I am not questioning the result and also believe it's most likely bitflips in a lot (most?) cases, but I would have really loved some more insight in that domain ... pun intended.
Earlier quoted context omitted.
I'm curious why that is evidence against the cosmic ray explanation. Couldn't it have something to do with the physical layout of memory? Perhaps those page-boundary-adjacent addresses present a larger physical target, perhaps on the bus. Of course I am wildly speculating right now. I'd love to see the article if you have a link!
This is tangential, but "Cosmic rays do not cause bit flips at a significant rate" is the default position and does not need supporting evidence. It's like if I claimed that planes occasionally crash due to a local density of dark matter pulling them down. Nobody would need to provide evidence against my theory, it's outrageous. I'm the one who has to provide the evidence.
No it's not. It's very well accepted in the silicon industry that cosmic ray events (the secondary particles) are responsible for enough bit flips that they have to be concerned with designing robust circuits and logic to achieve desired failure rates.
https://www.microsemi.com/document-portal/doc_view/130760-ne...
14. Are radiation effects at ground-level just a theoretical problem?
No, based on FIT rate data from Xilinx UG116, the largest Virtex ®-6 device (XC6VLX760) with 184,823,072 configuration bits will have a nominal failures-in-time (FIT) rate of 176 at sea-level in New York. While this represents a mean time between failures (MTBF) of 648 years, a system comprised of 1,000 FPGAs would experience a failure every year. The same systems based in Denver would experience failures every few months.
15. Are there any widely reported incidents of errors due to charged particles?
Several incidents across many industries have been reported in recent years. Among these:
• In 2008, a Quantas Airbus A330-303 pitched downward twice in rapid succession, diving first 650 feet and then 400 feet, seriously injuring a flight attendant and 11 passengers. The cause has been traced to errors in an on-board computer suspected to have been induced by cosmic rays. Modifications were undertaken to mitigate such errors in the future.
• Canadian-based St. Jude Medical issued an advisory to doctors in 2005, warning that SEUs to the memory of its implantable cardiac defibrillators could cause excessive drain on the unit's battery.
• Cisco Systems issued a field notice in 2003 regarding its 1200 series router line cards. The noticed warned of line card resets resulting from SEUs.
Unavoidable atmospheric neutrons remain the primary cause for SEU effects today.
One of the most important reliability concerns for silicon circuits is soft errors in SRAM circuits, which involves electrical upsets generated by the interaction of energetic atomic and subatomic particles with the silicon substrate material. SRAMs are particularly sensitive to radiation-induced soft errors due to the relatively low amount of charge at the storage nodes. Errors are generated by the impact of alpha particles emitted from trace amounts of uranium in solder and packaging materials of the circuit, and by neutrons that originate in the cosmic ray shower in the Earth’s atmosphere.
Even in the absence of on-chip sources of radiation, recent studies have conclusively proved that terrestrial cosmic rays (primarily neutrons) are a significant source of soft errors in both DRAMs and SRAMs [169-171]. Upsets have been observed both at ground level and in aircraft and have been convincingly correlated to the altitude and latitude variation of the neutron flux [172,169,171]. Lage, et al. have shown that even without alpha particles, a baseline of cosmic-ray upsets still exists for high-density SRAMs [170]. O’Gorman has shown that neutron upsets disappear for DRAMs placed 200 meters underground in a salt mine, while they increase dramatically for systems operated above 10,000 feet in Leadville, CO [169].
Even if we did not already have a large body of evidence to show that it was a concern, that would be untrue.
"Cosmic rays do not cause bit flips at a significant rate" is no less a claim than "cosmic rays do cause bit flips at a significant rate", and would require no less evidence. It does not somehow become the "default" just because it predicts little or no interaction.
If I wanted to reproduce bitflipping (from any source) on my laptop (any computer, really) over the shortest time frame possible, how could I conduct that experiment? Any pointers welcome.
Earlier quoted context omitted.
How does a comic bit flip make it past the Ethernet CRC?
It occurs in your machine before hitting the network.
If those computers are scribbling over memory at random, then that's occasionally going to cause some crashes, but much more commonly result in silent data corruption.
I don't know folks. 2 years ago I took a laptop which I wasn't using (16 GiB RAM non-ECC) => I created in Linux with Python an array ("bytes"? Don't remember exactly anymore) of ~10 or 12 GiB containing random integers => computed the array's hash and saved it. Then for ~1-2 months I recomputed from time to time the hash of that array (inbetween the laptop was in suspend-to-RAM) and compared it to the original result…
I've always been a bit skeptical of published numbers. I usually just chalk it up to vastly different operating conditions and scale. On my home server w/ ECC you can check the corrected and uncorrected (multibit) errors. Assuming my Ryzen is correctly reporting them to Linux, I have 0 errors corrected and 0 uncorrected with a 80 day uptime. I've checked a few other times and never seen an error. Others with ECC ofte…
But DDR4 and before does not I think.
I don't know folks. 2 years ago I took a laptop which I wasn't using (16 GiB RAM non-ECC) => I created in Linux with Python an array ("bytes"? Don't remember exactly anymore) of ~10 or 12 GiB containing random integers => computed the array's hash and saved it. Then for ~1-2 months I recomputed from time to time the hash of that array (inbetween the laptop was in suspend-to-RAM) and compared it to the original result…
The large mutable state like this tends to stress the memory bandwidth, so I’m not sure it’s related, but we used ECC memory and saw a seriously insane number of corrected bit flips.
Somewhere in the order of 100/s over the whole fleet as a baseline.
there were times that this rate spiked due to a faulty RAM stick, but if you look at the distribution it was fairly even, though there were fairly random hotspots.
After observing this I decided I didn’t want to live without ECC on my personal life, to my surprise there is no laptop on the market that supports ECC. Or at least none that I could find.
This issue goes away with DDR5 and built-in ECC though, or, our visibility of it does. So, I’m happy.