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
For a brief period, the Windows kernel tried to deal with gamma rays
101–110 of 124 posts
Re: For a brief period, the Windows kernel tried to deal with gamma rays
#102A 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…
Re: For a brief period, the Windows kernel tried to deal with gamma rays
#103If 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…
Re: For a brief period, the Windows kernel tried to deal with gamma rays
#104Invalidating 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…
Re: For a brief period, the Windows kernel tried to deal with gamma rays
#105Invalidating 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.
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
#106Embedded 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…
Re: For a brief period, the Windows kernel tried to deal with gamma rays
#107Earlier quoted context omitted.
In layman's terms, it's being continuously refreshed.
No its not, that is what makes it fundamentally different than DRAM.
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
#108Earlier quoted context omitted.
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
#109I found this code as an intern at Microsoft, while the manufacturer is hidden in the post, I'll give you a clue - the company starts with "I" and ends with "ntel"
Re: For a brief period, the Windows kernel tried to deal with gamma rays
#110Earlier 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…
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.