Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

For a brief period, the Windows kernel tried to deal with gamma rays

blogs.msdn.microsoft.com

Post reply on HN
Print view View original

91–100 of 124 posts

Re: For a brief period, the Windows kernel tried to deal with gamma rays

#91

Post by nonbel »

datenwolf wrote: post #49

Invalidating the caches is kind of a cringe inducing approach on this (actual) problem. Especially in HPC radiation related single event upsets have become a real problem. If you do the math, all the silicon area devoted to memory (DRAM, caches, registers) adds up, and what you've got is essentially particle detector. Compared to the effective volume of a purpose designed one (ATLAS, CMS, Super Kaminokade, etc.) rath…

>"1 event per day per 10^12 transistors"

Why is this in such an inconvenient form? If I have x gb of ram how many unavoidable memtest errors should I expect per hour of testing? It seems like that could be used to tell us the minimum amount of time to run the test.

Re: For a brief period, the Windows kernel tried to deal with gamma rays

#92

Post by trelliscoded »

Embedded people deal with this all the time. One class of solutions involves a checker task running continuously, which verifies the integrity of the data structures, kind of like a poor man's ECC. Really important code generally does everything three times, so there's a tie breaker in case there's a temporary fault in code or memory. I've seen this done with macros in ways that result in pretty wild code, like running a computation three times, storing each of those results three times, and then comparing the resulting nine outputs three times. That was in a diving related application, so it's not crazy to do all that work over and over since it had to be right.

Complex embedded systems like your cellphone's baseband processor usually just give up at some point and suicide a task or even the whole OS if they detect a problem. For a while I had a Qualcomm debugger attached to the internal cell modem I had in a netbook I was working on, and the baseband crashed all the time due to hardware faults. I thought I had a bad chip for a while until I realized it never happened when I left it in an underground parking lot.

Re: For a brief period, the Windows kernel tried to deal with gamma rays

#93

Post by acdha »

dfox wrote: post #87
groestl wrote: post #52

Earlier quoted context omitted.

> Bit flips in network surely is many orders of magnitude worse Yes, but because it's so prevalent that people expect it, they've added checksums on multiple levels, so the network actually performs better. In this particular instance (DNS queries), it's very unlikely that the data was corrupted in transit: "We believe that UDP checksums are effective at preventing 'bitsquat' attacks and other types of errors that oc…

One thing to keep in mind is that the network protocols usually use quite weak and similar checksums. To the extent that there are layer combinations that reliably produce errors that are not detectable by TCP checksum.

Has anyone published results on the impact of large scale TLS deployment on reliability? I’ve seen some older papers on errors which TCP missed but it seems like making a hard fail would be a nice win as the crypto overhead keeps getting cheaper.

Re: For a brief period, the Windows kernel tried to deal with gamma rays

#94

Post by Filligree »

nonbel wrote: post #91
datenwolf wrote: post #49

Invalidating the caches is kind of a cringe inducing approach on this (actual) problem. Especially in HPC radiation related single event upsets have become a real problem. If you do the math, all the silicon area devoted to memory (DRAM, caches, registers) adds up, and what you've got is essentially particle detector. Compared to the effective volume of a purpose designed one (ATLAS, CMS, Super Kaminokade, etc.) rath…

>"1 event per day per 10^12 transistors" Why is this in such an inconvenient form? If I have x gb of ram how many unavoidable memtest errors should I expect per hour of testing? It seems like that could be used to tell us the minimum amount of time to run the test.

DRAM uses one capacitor and one transistor per bit, iirc, so about one bit-flip per two years per GB.

Re: For a brief period, the Windows kernel tried to deal with gamma rays

#95

Post by nonbel »

Filligree wrote: post #94
nonbel wrote: post #91

Earlier quoted context omitted.

>"1 event per day per 10^12 transistors" Why is this in such an inconvenient form? If I have x gb of ram how many unavoidable memtest errors should I expect per hour of testing? It seems like that could be used to tell us the minimum amount of time to run the test.

DRAM uses one capacitor and one transistor per bit, iirc, so about one bit-flip per two years per GB.

Thanks, I saw that same value after a quick search but wasn't sure about it. That seems a bit high.

So if you have 128 gb, you would expect 128/104 ~ 2.5 bitflips per week, about every other day?

Re: For a brief period, the Windows kernel tried to deal with gamma rays

#96

Post by PhasmaFelis »

nonbel wrote: post #95
Filligree wrote: post #94

Earlier quoted context omitted.

DRAM uses one capacitor and one transistor per bit, iirc, so about one bit-flip per two years per GB.

Thanks, I saw that same value after a quick search but wasn't sure about it. That seems a bit high. So if you have 128 gb, you would expect 128/104 ~ 2.5 bitflips per week, about every other day?

128/104 would be ~1.23 bitflips per week.

Re: For a brief period, the Windows kernel tried to deal with gamma rays

#97

Post by nonbel »

PhasmaFelis wrote: post #96
nonbel wrote: post #95

Earlier quoted context omitted.

Thanks, I saw that same value after a quick search but wasn't sure about it. That seems a bit high. So if you have 128 gb, you would expect 128/104 ~ 2.5 bitflips per week, about every other day?

128/104 would be ~1.23 bitflips per week.

Ha, yea. Here is the calculation I did (carelessly):

  > 128/54
  [1] 2.37037
Still, one a week seems high.

Re: For a brief period, the Windows kernel tried to deal with gamma rays

#98

Post by Xcelerate »

spullara wrote: post #19

If you don't believe in bit flips, try this! http://dinaburg.org/bitsquatting.html I did that for a bit on cloudfront.net and got dozens of them in a short amount of time.

From your link,

> Bitsquat traffic represents a slice of normal traffic

Wow. That's pretty amazing. With enough analysis, you could (possibly) recover the traffic pattern for major websites. That alone seems to have a lot of interesting implications.

Re: For a brief period, the Windows kernel tried to deal with gamma rays

#99

Post by throwaway2048 »

russdill wrote: post #83
blattimwind wrote: post #13

Earlier quoted context omitted.

> Contrast this with processor cache. On-die cache is most likely SRAM, Static RAM. It doesn't get refreshed. So the slight voltage errors caused by gamma rays can slowly build up over time. Static RAM is basically a flip-flop. It's a bistable circuit that's actively held in a stable state. Single-event upsets work by, essentially, putting the energy into the circuit required to make it transition into the opposite s…

In layman's terms, it's being continuously refreshed.

No its not, that is what makes it fundamentally different than DRAM.

Re: For a brief period, the Windows kernel tried to deal with gamma rays

#100

Post by ZakNichol »

trelliscoded wrote: post #92

Embedded people deal with this all the time. One class of solutions involves a checker task running continuously, which verifies the integrity of the data structures, kind of like a poor man's ECC. Really important code generally does everything three times, so there's a tie breaker in case there's a temporary fault in code or memory. I've seen this done with macros in ways that result in pretty wild code, like runni…

This. Cache is the least of their worries in aerospace. It's common to see satellite IC's dosed up so high on the ol' Gamma that the silicon MOSFET junctions themselves start disintegrating.
Post reply on HN