Slashdot Mirror
MRAM Inches Towards Prime Time
levin writes "According to an article over at EETimes, magnetoresistive RAM chips are getting a little more practical. Infineon Technologies released info on a new 16M MRAM component on Tuesday and the read and write cycle times of this chip make it 'competitive with established DRAM.' How long before nonvolatile memory becomes the solution to crash-prone software rather than better programming?"
Last time I checked, most of the software crashes aren't caused by memory randomly disappearing.
How long before nonvolatile memory becomes the solution to crash-prone software rather than better programming?
Probably very long......
There are very little volatile-memory related software bugs.....
HINT: You don't want your ram back in the same corrupt state it was in before the reboot.
Jeroen
Secure messaging: http://quickmsg.vreeken.net/
Looks cool for applications such as hibernate.
How is nonvolatile RAM supposed to prevent crashes? Crashes are the result of unexpected program interaction, hardware incompatibilty, or poorly-anticipated user input.
"How long before nonvolatile memory becomes the solution to crash-prone software rather than better programming?"
Never. Having the same bits in memory after a reboot doesn't help if you wrote the wrong bits in the first place.
"On two occasions I have been asked, 'Pray, Mr. Babbage, if you put into the machine wrong figures, will the right answers come out?' I am not able rightly to apprehend the kind of confusion of ideas that could provoke such a question."
~Lake
Non-volatile main memory is unlikely to be a solution against crash-prone software. If the software crashed because there was a bug in how it handled the data in memory, if the data is still there and the application reads it again, it'll just crash in exactly the same place.
In any case, an application crashing very seldom causes the machine to actually power down, and an application crashing and being restarted never gets to use the same memory the same way anyway, so the point is entirely moot. If your main memory is nonvolatile RAM, the advantage is you can design a system that can be powered down and suspended without having all that lengthy write of the entire machine's state to disk (and read when it comes back up again), which would be extremely useful on a laptop. If you can do this, you can have essentially uptime of years, so the incentive would be to write MORE stable operating systems and applications if the expectation is that even a laptop may go years between reboots.
Oolite: Elite-like game. For Mac, Linux and Windows
Once step closer to replacing HDD, CDROM, DVD and all those other "moving parts" storage devices.
In 20 years, we'll all be looking back at DVD and CDROM like we do at Tape Cassette.
Moving parts and things that go whirr make me cringe.
I just want to plug it in and get instant access.
The real future is in ENRAM. Give it all your money and then it crashes !
A Multiplayer Strategy Game for Mac OS X, Windows, and Linux
You turn it off in the first place? :o
Yay! We're going to get instant-on computers, just like home computers in the '80s were. How are we going to achieve it? Some form of jumped-up magnetic core memory!
In soviet russia stale jokes recycle you!
There are very little volatile-memory related software bugs.....
Oh, are you SURE about that? You should research such statements first, my friend, rather than assuming.
Take a look at this review from last year of power supplies by Anandtech.
They ran a six-hour memory test 54 times--and found that with 512MB of RAM, after each six hour test there were an average of four bits that had flipped! That means there is a memory error on a 512MB PC--on average--every 90 minutes!
If that error occurs in a code segment in a driver, you may get a system crash. In a Windows DLL, perhaps some system instability. In an application, perhaps an application crash. If it's in a data segment, your important manuscript may suddenly lose a paragraph or skip a couple pages as a linked list pointer jumps to the wrong spot, or you may find a bunch of junk replacing normal text.
Memory errors are a serious problem that very few people acknowledge. Why people still buy non-ECC RAM is beyond me. (Of course, even with ECC RAM, there are still various places inside the PC where failure can occur--along the various buses for exmaple, which don't all have ECC. So this is only part of the solution.)
More reliable RAM would definitely be a step in the right direction.
The magnetoresistive cell can change the way ANY sequential logic circuit operates. It can make much denser CPUs, ASICs and FPGAs, because now you can make the clock input be THE power supply line.
... well, longer.
It can also make your timepiece battery last
You just need to look at it in a different view then Yet Another Non-PowerCycle-Erasable Storage.
Now one thing Novell is not is stupid. They refused.
Somehow, the story of the challenge got around the exhibition floor, and a crowd assembled. Perhaps it was gremlins. Never eager to pass up an opportunity, the keykos staff happily spent the next hour kicking their plug out of the wall. Each time, the system would come back within 30 seconds (15 of which were spent in the bios prom, which was embarassing, but not really key logic's fault). Each time key logic did this, more of the audience would give novell a dubious look.
Eventually, the novell folks couldn't take it anymore, and gritting their teeth they carefully turned the power off on their machine, hoping that nothing would go wrong. As you might expect, the machine successfully stopped running. Very reliable.
Having successfully stopped their machine, novell crossed their fingers and turned the machine back on. 40 minutes later, they were still checking their file systems. Not a single useful program had been started.
Figuring they probably had made their point, and not wanting to cause undeserved embarassment, the keykos folks stopped pulling the plug after five or six recoveries.
Want to improve your Karma? Instead of "Post Anonymously", try the "Post Humously" option.
And how exactly is one expected to code against this?
It's not difficult.
Just add ECC in software.
I've done this before in some of the software I've written for hospitals and banks; it's been a design requirement for the software to detect when there is a failure, and to correct if possible.
And, yes, failures ARE detected, AND corrected.
The way it works is you divide memory up into blocks (for example, 512 bytes of 1KB). You do this for both your data and code. For each memory block, store the ECC data (usually, in a separate area of memory, so it's non-intrusive to the program design).
A thread runs in the background, often on a second CPU, continuously checking the program's data and code to ensure that the ECC data is valid. When an error is detected, it is logged and corrected if possible.
When modifying data, a flag is set for that memory block that it has been altered; a new ECC value is calculated as soon thereafter as possible. (This is done automatically by setting the CPU to generate an exception when writing to a particular segment. It's a feature built into Intel processors and available through high-level calls in both Windows and Linux.)
I'm sure you remember the Java exploit from a couple of years back, where the security model was bypassed completely by blowing a hairdryer on the RAM until a byte code error was induced in very-carefully-constructed code. Software ECC is the kind of thing you need to do to mitigate those types of attacks.
No, that's wrong. The truth is that errors in dynamic RAM can be introduced on each refresh. As you said yourself, dynamic RAM needs to be refreshed every few milliseconds--read and rewritten. Each time that happens, it's possible for an error to be introduced. If the refresh circuitry reads the value incorrectly, you get an error. If it writes the value incorrectly, you get an error. The longer the RAM sits around, the more refresh cycles, so the greater the chance for errors. If the voltages aren't stable enough, for example, you'll find a "1" bit refreshed with slightly too low of a current so that when the next refresh comes around, it's read as a "0" as it's been discharging over time and falls just below the threshhold to be read as a "1".
As far as errors not being introduced when the memory is "idle," you're thinking of static RAM. Static RAM doesn't need to be refreshed, and thus actually CAN be idle. So it holds a huge advantage here. Without the refresh cycle, there's no place for errors to be introduced except during the actual reads and writes by the processor.