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?"
That being said, imagine the power savings and lightning fast startup times! I'd love an "instant on" PC! ( or, erm...Mac
CAn'T CompreHend SARcaSm?
Someone explain to me how MRAM will help with stability if it is simply replacing the same type of functionality that good old fashioned RAM has.
My sig is blank, I typed this by hand.
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.
"How long before nonvolatile memory becomes the solution to crash-prone software rather than better programming?"
Hello. What do you think -hard disks- are?
I'll give you 5 seconds to come up with a list of operating system 'features' that have been 'standardized' which really resulted from this 'ideology' about how to not write 'safe' code and just let other parts of the system 'deal with it'
Give up? Okay, I'll give you a few:
1. Swap. Yup, if the program has no idea how much RAM it has or needs, and no idea how to manage it, and the programmer just wants it all
2. "Protected Memory". Yup. Same deal. Let the OS deal with 'bad programming'.
Non-volatile memory has nothing to do with 'protecting from bad programming' and everything to do with writing 'true' persistent state machines... just like these two 'features'.
In summary: If it wasn't for 'bad programming', operating systems wouldn't have anything to do
Flame on.
; -- the corruption of government starts with its secrets. a truly free people keep no secrets. --
Wouldn't non-volatile RAM actually make programmers more attentive?
/proc ?) like any other file. Then, determining which program was leaking ram could be done with a simple `ls -la`.
One of the most common programming errors is a memory-leak. Can you imagine what would happen if you couln't reboot the Windows machine to clear the memory for another few days?
Non-volatile RAM may be the best excuse yet to switch to something more, ah... tightly coded!
That said, I think that the current memory/disk model of computing is antiquated. Why distinguish memory from disk? Why not treat it all the same?
A HDD is the base storage medium. RAM is a cache of that. L2 cache is a cache of RAM. L1 cache caches L2 cache.
Why the distinction from HDD to memory? Instead of allocating RAM directly, why not follow the *nix philosophy of "everything is a file" and if you want a storage space for some temp values, open a file and write them in.
The memory allocated for a particular process would then appear as a file (perhaps buried somewhere in
Instead of flushing to special swap partitions, the memory files would simply be committed to disk when you run out of RAM. (moved down the cache chain from RAM to disk)
Switching to a fundamentally different type of memory may be the right time to reconsider system architectures and challenge our conventional assumptions of computing, especially since memory leaks can be so severe, even in commercial software!
I have no problem with your religion until you decide it's reason to deprive others of the truth.
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.
Err, then the PC and ram Anandtech have been using are dodgy.
Due to the design of Dynamic RAM chips, memory bit flip errors are not influenced by how long the memory sits "idle". I emphise idle here because Dynamic ram is never really idle. Each cell in a DRAM chip contains a capacitor and a transistor. If a DRAM cell is left to its own devices, the capacitor soon discarges and the cell looses its state. To stop this from happening, in the background, the RAM controller on the chip is constantly recharging the capacitors. Each cell is read and rewritten about every few milliseconds.
Because DRAM chips are never idle, the whole methodolgy of the anandtech test is WRONG, and the most obvious conclusion is that anandtech is using dodgy ram, or is simply pushing the RAM beyond their specs to forcibly generate errors.
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.