SoylentNews is people
SoylentNews
A nanotube-based non-volatile RAM product could give Intel/Micron's 3D XPoint some competition:
Fujitsu announced that it has licensed Nantero's carbon nanotube-based NRAM (Non-volatile RAM) and will participate in a joint development effort to bring a 256Gb 55nm product to market in 2018. Carbon nanotubes are a promising technology projected to make an appearance in numerous applications, largely due to their incredible characteristics, which include unmatchable performance, durability and extreme temperature tolerance. Most view carbon nanotubes as a technology far off on the horizon, but Nantero has had working prototypes for several years.
[...] Other products also suffer limited endurance thresholds, whereas Nantero's NRAM has been tested up to 10^12 (1 trillion) cycles. The company stopped testing endurance at that point, so the upper bounds remain undefined. [...] The NRAM carbon nanotubes are 2nm in diameter. Much like NAND, fabs arrange the material into separate cells. NAND employs electrons to denote the binary value held in each cell (1 or 0), and the smallest lithographies hold roughly a dozen electrons per cell. NRAM employs several hundred carbon nanotubes per cell, and the tubes either attract or repel each other with the application of an electrical current, which signifies an "on" or "off" state. NRAM erases (resets) the cells with a phonon-driven technique that forces the nanotubes to vibrate and separate from each other. NRAM triggers the reset process by reversing the current, and it is reportedly more power efficient than competing memories (particularly at idle, where it requires no power at all).
NRAM could be much faster than 3D XPoint and suitable as universal memory for a concept like HP's "The Machine":
NRAM seems to be far faster than XPoint, and could be denser. An Intel Optane DIMM might have a latency of [7-9 µs] (7,000-9,000ns). Micron QuantX XPoint SSDs are expected to have latencies of [10 µs] for reading and [20 µs] for writing; that's 10,000 and 20,000ns respectively. A quick comparison has NRAM at c50ns or less and XPoint DIMMs at 7,000-10,000ns, 140-200 times slower. We might imagine that an XPoint/ReRAM-using server system has both DRAM and XPoint/ReRAM whereas an NRAM-using system might just use NRAM, once pricing facilitates this.
Another company licensing with Nantero is already looking to scale the NRAM down to 28nm.
(Score: 3, Informative) by butthurt on Friday September 02 2016, @12:00AM
The type of attack you're thinking about is already possible with the capacitive memory--so-called dynamic RAM (DRAM)--that we use now. It's called a "cold boot attack": at cryogenic temperatures, today's RAM retains its contents for hours.
https://en.wikipedia.org/wiki/Cold_boot_attack [wikipedia.org]
One approach to defending against it is the use of encrypted RAM. The trouble is, the encryption key needs to be stored somewhere.
http://tastytronic.net/~pedro/docs/ieee-hst-2010.pdf [tastytronic.net]
static RAM (SRAM) such as that built into microprocessors is, as far as I know, not subject to that attack: it stores information in transistors that are switched on or off. Once power is no longer applied, that information should vanish (unless I'm mistaken). DRAM is fast, expensive, and uses a lot of power. Keeping one's encryption keys in SRAM and encrypting the contents of RAM could be a viable way to defend against a cold boot attack (amusingly, such a defence would use the dynamic quality of static RAM to overcome the static quality of dynamic RAM). It might require SRAM that's separate from the microprocessor.
(Score: 3, Interesting) by TheRaven on Friday September 02 2016, @08:39AM
There's been some work on power-efficient GPU memory taking advantage of this by having longer refresh cycles for the lower bits. In most uses, users won't notice a 10% probability of bit flips in the lowest bit of a coordinate or colour. By gradually increasing the refresh cycle time, you have almost zero probability of error for the most significant bits, moving to quite low probability of error for the least significant bits. Particularly for memory that's being used as a render target (so if you do get bit flips, you'll recreate the data next frame anyway) this can give quite a big power saving without introducing artefacts that the user notices. Don't do this for scientific computing / GPGPU stuff though!
[1] Although a lot less bad than you'd think. A colleague of mine did some work a while ago showing that bit flips can allow you to escape from the JVM. As part of this, he held a hairdryer to the RAM chips to flip bits at random. It took quite an astonishing number of DRAM errors before most software noticed. It basically had to be a flip in a pointer, and often with alignment requirements it had to be either a very high bit or a low bit in a pointer to something that wasn't an array.
sudo mod me up
(Score: 2) by Geotti on Friday September 02 2016, @10:48AM
[...] this can give quite a big power saving without introducing artefacts that the user notices. Don't do this for scientific computing / GPGPU stuff though!
And don't do this with WOPR [wikipedia.org]!