Slashdot Mirror
NASA Update Will Deal With Opportunity Flash Memory "Amnesia"
BarbaraHudson writes Computerworld has some details on NASA's latest fix to allow the Opportunity Mars Rover to store data while in overnight "sleep mode." Opportunity has been suffering from a glitch that's causing what NASA scientists describe as memory and data loss — or robotic "amnesia" — caused by flash memory deterioration since early December. Currently any information gathered is stored temporarily in RAM and must be sent to Earth so it's not lost when Opportunity powers down.
And you think a spinning hard drive with platters and heads would be a better choice for a spacecraft that has to endure several G forces worth of acceleration at each end of the trip? Or perhaps it's a better choice to use magnetic media than solid state in high radiation environments like interplanetary space?
I want peace on earth and goodwill toward man.
We are the United States Government! We don't do that sort of thing.
Actually, the amount of NAND in Opportunity is 256MB, which isn't a lot. RAM is only 128MB; NAND is routinely given a full wipe and rewrite. Given it was only meant to last for 90 days, it's probably a low-grade MLC with under 5000 erase cycles reliability.
By contrast, a desktop SSD of 32-256GB will see a daily write cycle of under a gigabyte per day. The documents, cache, e-mails, and updates per day total very little--hundreds of megabytes, at best--for most workloads, up to and including intensive workloads such as 3D modeling and multi-layer 2D image editing, which produce massive work sets but only make minor changes to them. Large workloads include video editing, which does write multi-gigabyte files out on each large render operation (which may be frequent in some workflows).
System drive SSDs see small workloads even when used as a swap device: swap offloads a lot of stale memory from RAM, which is either hardly ever used, never written to, or simply stale. The brk() area can have fragmented holes too small to take new allocations, and so may page out entirely unused RAM to disk; much RAM (such as GUI elements, textures, models, and audio assets) contains load-once data that's written to disk when swapped, and then only read later, such that it's left on swap and evicted from RAM without writing out again when memory gets scarce. That means 2GB of swap might be 2GB of writes since boot time, plus maybe a hundred megabytes or less per day of continuous system run.
Finally, system drives also wear level internally. Writing to the same 1MB area over and over will spread the writes out: the controller will internally account for those blocks being erased and rewritten elsewhere, often by additive writing (writing without erasing) to avoid wearing the drive (e.g. you can have a used and erased map, in which anything erased or not used is free; you can then write to the used map and to the erased map, until you run out of free blocks and need to erase a newly used block, and thus need to mark all used-erased blocks free and mark no blocks as erased, costing one write-erase cycle even though you've written thousands of times). You'll get a full write-erase cycle every full data width write: even if you write to the same spot repeatedly, you only use one write-erase cycle writing 32GB to a 32GB drive, or 256GB to a 256GB drive.
Accounting for all this, the drives are quite long-lasting. For a 10,000 cycle drive, you'd have to write 320,000GB to a 32GB SSD or 2,560,000GB to a 256GB SSD to wear it out. That's 876 years at 1GB per day for a 32GB drive, or over 8 years if you're writing 100GB per day. For a 256GB drive, it's 7000 year-gigabytes, or 70 years if you're writing 100GB per day. Modern MLC NAND can survive 100,000 write-erase cycles before failure, so these lifetimes may be 10 times higher; high-end SLC drives can survive 10,000,000 write-erase cycles, and can back high-traffic SANs for decades.
They actually burn out less frequently than hard drives.
Support my political activism on Patreon.
I've never been a big fan of flash memory, given that it has a finite number of write cycles before a memory bit fails (varying between 1 and 100million write cycles). The probability may be low that an individual bit may need to flip so many times in it's lifetime, but it's still an issue.. A lot of care must be taken by the firmware engineer to handle this. There are a lot of job postings for firmware engineers that understand flash..
I'm a huge fan of FRAM. It has a lifecycle limit that is quoted at being 10 trillion write cycles (some mention at it being infinite). The memory density is lower, but is a lot more reliable. It's biggest issue is that the density is lower. For a spacecraft, I'd much rather have a board of these 2Mbit FRAMS then a large flash chip. They use these things in smart meters, etc. In embedded systems, you have to be really careful not to write to the flash too often out of risk of damaging the flash. Most fast SD cards have their own dedicated microcontroller (ARM9, etc) to do what they can to extend the life of the flash..
A datasheet of an FRAM device: http://www.fujitsu.com/downloa...
One question I have is how FRAM compares to NAND-flash in a harsh radiation environment, and what are the radiation differences on mars vs the earth. How many vendors offer rad-hard processes for FRAM, and how do they perform?
Here is one link I could find on FRAM, but the report from 2011 is not clear:
http://cdn.intechopen.com/pdfs...