Live data from Hacker News

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

blogs.msdn.microsoft.com

101–110 of 124 posts

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

#101
post #77

Earlier quoted context omitted.

Unless you know what you are doing, you might want to delete that. Probably goes against the NDA you've signed, no?

The comment with Intel was already mentioned in 2008 at https://deadracoon.livejournal.com/87049.html

He's my old boss :)

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

#102

A bunch of years ago Cisco had an issue with some RAM in a new switch model, I think it was in the 65xx. They where crashing randomly but only in certain places in the world. Cisco spent tons of money on this. No idea. They brought in a physics professor. The devices with the most issues were located in countries up near the artic circle. Cosmic Rays caused a bit flip in this particular set of RAM due to something in…

Low alpha solder used to come from lead ballast lost at sea. This was supposedly a valuable resource for deep sea treasure hunters.

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

#103
post #29

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.

Bit flips in network surely is many orders of magnitude worse than in cache/memory bit flips? And I doubt it has to do with gamma rays. Those with poor or long distance DSL do see a big increase in errors. And while hopefully getting rarer now home routers could easily overheat and introduce errors as soon as they saw more than usual traffic. We recently had issues with the power supply for our router and it also cau…

So Ethernet is protected by CRC which is quite good, but it is stripped at both ends and I would not trust the routing chips at all. Some core routers used low reliability FPGAs for example..

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

#104

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…

An article I read awhile ago addressed an interesting correlation between transistor process size, the physical size of the dram module and the expected failure rates. "As transistor sizes have shrunk, they have required less and less electrical charge to represent a logical bit. So the likelihood that one bit will "flip" from 0 to 1 (or 1 to 0) when struck by an energetic particle has been increasing. This has been…

How much shielding would it take to prevent most of these energetic particles from reaching the important bits?

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

#105

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…

Could physicists and astronomers use all this distributed particle detection for research? Like a app in a phone or desktop that sends reports back with location and time information.

To me, this seems like AstroTurf PR for the quoted manufacturer's Movidius™ Myriad™ 2, just tested at [hope to be trendy HEP institution].

Pity the photo with friendly smiles from the press package was left out, but the curious will find it with a brief search.

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

#106

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…

Or for really serious stuff, 3 processors running 3 implementations from the same spec, voting.

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

#107

Earlier quoted context omitted.

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

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

Yes, it is. That's what makes it fundamentally different from DRAM, which isn't being continuously refreshed, which is why the memory controller has to manually refresh DRAM at frequent intervals. DRAM has much simpler cells, at the cost of more complex control logic.

I recommend you just take a look at Wikipedia or something for an explanation of SRAM. Each bit is typically implemented using six transistors, four of which form a loop of two inverters.

They are continuously powered, which causes the continuous refresh the parent was talking about.

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

#108

Earlier quoted context omitted.

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

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

If it's 3.3V logic, and the voltage dips for some reason to 3.0V, it will immediately rise back up to 3.3V. A DRAM cell would stay at 3.0V until the next refresh cycle. That's what I mean by a layman's "continuously refreshed". It has constant input power keeping the voltage at the same level.

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

#110

Earlier quoted context omitted.

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

Yes, it is. That's what makes it fundamentally different from DRAM, which isn't being continuously refreshed, which is why the memory controller has to manually refresh DRAM at frequent intervals. DRAM has much simpler cells, at the cost of more complex control logic. I recommend you just take a look at Wikipedia or something for an explanation of SRAM. Each bit is typically implemented using six transistors, four of…

There is no continuous "refresh". The circuit is bistable which means that the system has two states in which, once reached, it will remain until some energy is expended to change that.

Imagine it like two valleys with a hill between. Rolling a ball from the OFF valley to the ON valley requires some energy. If it's not enough the ball rolls back into the valley it's currently in.

The process is entirely analog, ie, there is no refresh circuit that looks at the voltage and says "that's almost a ON, better fresh up the voltage". The output of the circuit is digital. (You can play with the R/S latches of most SRAM on an oscilloscope and it's quite fun, the output of non-integrated SRAM will react in an analog fashion. If it's integrated, ie has a controller, this is not possible sadly)

Until you cross the threshold, the circuit will simply slide back to the original position, once you cross it, it'll slide into the new position without any additional effort.

Post reply on HN