• Welcome to SCdev.org. Please log in.

Welcome to the new SCdev forums!

Is it true ?

Started by Rodrigo, September 24, 2005, 11:36:38 PM

Previous topic - Next topic

satanduck

Did some research following my post up there (if anybody is interested at all).

It seems that later firmware has a mechanism to count the number of writes and erases on the memory card, and will spread out the later cycles across the card to minimise the effect of wearing out parts of the flash card.

Isn't technology just intriguing... hehehe
nimal Crossing :
Larson" from "Havenile" of Zip code "0816-6534-7899".
Mario Kart DS : 519750-640786 (Larson)
Tony Hawk : 137499-350825 (Larson)

PM me if you added me!

torne

Quote from: "satanduck"I've read some where many years ago about the write cycles of flash memory devices. There is supposed to be a limited number of write cycles (pretty huge number in the order of thousands) that each device is capable of before failing. I don't know how much have the technology matured over the years but these days alot of manufacturers seem to offer "Lifetime Warranty" on their flash based products, so its probably not applicable anymore.
No, there is and always will be a limited number of erase cycles (it's erasing, not writing, that's a problem - but since you can't overwrite data on flash memory it amounts to the same thing). Only switching to a totally different underlying technology would fix this. So yes, the SC will cause wear, but I wasn't really counting this as damage as it's unavoidable.

Quote from: "satanduck"To counter the "wear" I've always stick to the rule of buying a few sizes and using only what I need. i.e. if i'm gonna be shooting 256MB worth of pictures, I'm not going to slot in a 512MB card, so that the "write cycles" on the entire card is the same and not uneven. My rationale is that the entire card will wear out at the same time and not the first 256MB that wears out (due to constant re-use) and rendering the remaining 256MB (unused because only using first 256MB) useless. I don't know if it makes sense at all, its just sort of a "religion" kinda thing rather than a "scientific" thing.
This is, unfortunately, having the opposite effect to what you intend. If you only ever put 256mb of files on a 512mb card, it will take twice as long to wear out, and thus you gain both more life *and* more storage space.

See, all major memory card formats (SD, CF, MMC, MS, SM) implement a feature called "wear levelling". They don't directly expose the blocks of the flash chip to the computer - instead, all accesses pass through a remapping layer. When you try to write to a block, instead of erasing it and writing over it, it erases a new block instead and gives you that, then it internally marks the old block as unused. By doing this, it can ensure that all blocks are erased approximately as often as each other, by cycling through which ones are overwritten each time a write occurs.

Also, there are a moderate-to-large number of 'spare' blocks - these are not visible capacity. This is one of the reasons why a '64MB' card doesn't have 64MB of space on it - some blocks of the flash are reserved as spare. When the card detects a block that has not written correctly, it marks it as bad so it will never use it again, then retries the write onto one of the spare blocks. This is always happening, because manufacturing defects mean that most cards will have maybe one or two bad blocks right from the start. Once a block fails from wear (as the wear levelling is not *perfectly* even, and some blocks may be more prone to failure than others) it's replaced from spare and your computer doesn't even get told about it ;) Only when all spare blocks have been used and there is no more 'room' to do block remapping does the computer receive a write error, and until this point, all your data is safe.

So, you are actually better off buying the largest card you can afford, rather than the smallest one that will hold the files: larger cards have more blocks to level over (reducing the number of times any particular block is written, and thus increasing life), larger cards have more spare blocks (increasing the number of dead blocks they can tolerate), and larger cards may even have slightly better wear levelling algorithms.

This is how they offer 'lifetime warranties' - they check the cards at manufacture to ensure they have no more than a certain number of defects, their process generates flash blocks that can be erased tens of thousands of times, they allocate anything up to about 7-8% of the blocks to use as spare, then they slap on the biggest baddest wear levelling algorithm they can. The result may be a card that can survive at least several billion block writes before developing a user-visible error, and thus they feel safe in warrantying it ;)

Note that this does *not* apply to USB flash memory things (the typically keyring-shaped memory sticks), only to accepted memory card standards. USB flash memory usually has no wear levelling at all, and no bad block remapping, because the wear levelling and block remapping process is heavily patented (mostly by Samsung) and the manufacturers of cheap USB memory can't afford to licence the patents as their profit margins are already very slim. This is compounded by the fact that USB flash memory is usually formatted as FAT in order to support interoperability between a wide range of devices and operating systems - the file allocation table itself on a FAT filesystem is rewritten often, and is stored at the beginning of the flash in a fixed location, and thus the first few blocks of the card get erased far more often than any other, causing them to fail first and rendering the filesystem unusable. This can often be 'fixed' once it's occurred by repartitioning the device so the filesystem starts after all the bad blocks, but this obviously reduces capacity slightly, and might lead you to question the safety of your data ;)

Edit: Bah, took me way too long to write this, didn't realise you'd posted in the meantime. It's not firmware, it's hardware behaviour on the memory card, programmed in ROM.

satanduck

Wow

Well said! Way better than the wikipedia entry I was reading. Maybe you can update it? hehe...

Strange how a forum devoted to a gaming product can get so technical!
nimal Crossing :
Larson" from "Havenile" of Zip code "0816-6534-7899".
Mario Kart DS : 519750-640786 (Larson)
Tony Hawk : 137499-350825 (Larson)

PM me if you added me!

torne

Quote from: "satanduck"Well said! Way better than the wikipedia entry I was reading. Maybe you can update it? hehe...

Hehe. I'm a kernel developer for Symbian, who make the Symbian mobile phone OS. Most smartphones have big stacks of flash memory inside, and thus we have our own wear-levelling filesystems, licences for the Samsung patents, MMC/SD/CF/etc interface device drivers, and other stuff. I've spent far too much time messing around inside the Samsung bad block remapping code for my own comfort ;)

Experience with embedded OS development comes in handy when you come to disassembling horrible, horrible code like the Supercard stuff. I'm not making a lot of headway right now, as the code is seriously torturous and I don't have a lot of time free. I can see why save patching causes so much slowdown in some games, though - the interrupt trap executes almost a hundred instructions before returning control to the game's interrupt handler, including a bunch of moderately slow memory accesses, and a few CPU mode switches.. it's insane. It could probably easily be rewritten to be much faster, but it'd still be better to avoid trapping interrupts at all.

satanduck

Ahhh that explains it. I'm supporting a telecoms performance management software originated from the UK ;)

The only embedded programming I ever did was for my Palm using the horrible m86k cross compiler... though I briefly remember programming a 8051 micro controller in uni...

your work sounds like a lot of fun!
nimal Crossing :
Larson" from "Havenile" of Zip code "0816-6534-7899".
Mario Kart DS : 519750-640786 (Larson)
Tony Hawk : 137499-350825 (Larson)

PM me if you added me!

Ramin

OH YEAH?... WELL...

THE KIND OF PROGRAMMING I DO... IS.... UHM... LITTLE ".BAT" FILES THAT... ERM... DELETE STUFF AND STUFF.... YEAH...

WOO HOO!  8)

Ramin

But seriously, guys like you are the gods of these forums! We can only partake of the infinitesimal portions of your ample wealth of knowledge that you sprinkle upon us lowly ones.

Good job, guys... even though I can only understand a minimal percentage of the information you post, I feel much better informed because of it.

torne

Hehe. Well, I'm just hoping I'll be able to do something to help the card run better, for the benefit of all you fine folks (as well as myself, of course) ;)

krebalo

Quote from: "satanduck"
To counter the "wear" I've always stick to the rule of buying a few sizes and using only what I need. i.e. if i'm gonna be shooting 256MB worth of pictures, I'm not going to slot in a 512MB card, so that the "write cycles" on the entire card is the same and not uneven. My rationale is that the entire card will wear out at the same time and not the first 256MB that wears out (due to constant re-use) and rendering the remaining 256MB (unused because only using first 256MB) useless. I don't know if it makes sense at all, its just sort of a "religion" kinda thing rather than a "scientific" thing.

Flash card controller software itself manages (on low level) the "wear problem" to wear entire memory evenly. So your 512 (or 1024 MB) card may live even twice or more longer than 256 MB card because different memory segments are weared twice a less.

Edit: missed torne's explanation before :)

stupid2ass

Quote from: "torne"Hehe. Well, I'm just hoping I'll be able to do something to help the card run better, for the benefit of all you fine folks (as well as myself, of course) ;)
Well done good sirs.  It's not everyday I learn something educational from sites like these.  Takes me back to my Cmpt OS courses in Uni ...