Interesting discussion and very cool project. However, based on my flash experience, I think there are some misunderstanding to correct.
First, 10000 erase cycle assumption is incorrect on the 128MB range of internal memory, because on this class of flash memory, SLC (Single Level Cell) type of flash memory is used and it typically exceeds 100000 erase cycle per block which is 10x more thanyour original assumption. 10000 erase cycle is correct for MLC technology but the size of the MLC flashes are at least over 1GB due to the production efficiency. These days, 16Gbit (say 2GB) per die MLC flashes are used most and this will soon be replaced with 32Gbit(4GB) per die MLC flashes. Also, to compensate reduced endurance of MLC, flash s/w does more strict wear leveling technique. You mention the case that only 10MB free memories are available, however, even in this case, flash s/w keep track of erase count of all block (not just free block) and re- position the blocks so that all block can have similar erase count. In this way, the endurance of flash memory extends because the writes are evenly distribute to entire blocks of the flash. Second, erase time is not the order of second, but the order of millisecond. Erase only can perform per block basis which is 64KB ~ 256KB size and it took 1~3ms. Each block consist of multiple pages which is the unit of write and each page is 2KB or 4KB on current generation flashes. And each page write took 200us on SLC and 1000us on MLC. In summary, typical NAND flash have following characteristic. SLC : 100000 erase per block, block size: 64~128KB, block erase time : 2ms page size. 1~2KB, page write time : 200us MLC : 10000 erase per block. (for 2bit per cell technology) block size : 128KB ~ 256KB, block erase time : 2ms page size : 2KB ~ 4KB, page write time : 1000us On Sep 13, 5:27 pm, blindfold <[EMAIL PROTECTED]> wrote: > Hi David, > > Thank you for your explanation. Funny though that your calculation > works out *exactly* like I described when I go back to what you call a > pathological example. I'll show you, but first, > > > You give a pathological example of a 128MB card that's 90% full. > > Not at all unreasonable for typical users who gather MP3 files, take > photographs and so on. > > > In fact, you can't get 128MB SD cards any more > > Maybe, but what about the size of the phone's *internal* flash memory, > which I am currently using to cache synthesized audio. Not sure what > the anticipated HTC Dream / T-Mobile G1 will have, but just to look at > the new HTC S740 (http://www.htc.com/www/press.aspx?id=59830) I read > "Internal memory: 256 MB flash" which is of the same order as my 128 > MB example. In another thread I already inquired about the performance > of internal flash versus SD card, which is currently my primary reason > to pick one or the other for caching audio (again for lack of Android > API support to keep it all in RAM). Of course there also exist phones > with much more internal flash memory, but that does not take away the > current concerns. > > > Your sample application is MP3 streaming. Streaming at 128kbs will > > involve writing 16kB/sec > > No, my example is about in-memory CD quality audio synthesis, i.e. > without MP3 compression. 44100 * 16 bits per sample * 2 channels (for > stereo) gives you 176 kB/s. > > > This means there are only 204 cells, which means only 2040000 writes, which > > comes to 8160000 seconds = 94 days. > > 94 days * (16kB/s) / (176kB/s) * 24 hours/day ~= 200 hours, just like > I wrote before. > > Or back to the more theoretical (or malware?) maximum load example of > 10 MB/s, > > 94 days * (16kB/s) / (10,000kB/s) * 24 hours/day ~= 3.5 hours, just > like I wrote before. > > The whole cell load spreading consideration does not apply because I > am already *evenly* overwriting each and every bit of the remaining > storage (OK, likely 50% of the bits remain at the same value, but you > get the idea). No low level cell allocation management can do better > than this even spread that I already assume. You are right though that > apart from wear there can also exist significant performance penalties > due to the slow erase. My own application requires a latency well > below one second to perform well. So this Android MediaPlayer > limitation can work out pretty badly, and is easily avoidable at API > level by simply supporting the same basic MediaPlayer functionality > that has been in Java ME (J2ME) for many years already. "Cache to > flash" should not be required, and is simply asking for trouble. > > On Sep 13, 2:22 am, David Given <[EMAIL PROTECTED]> wrote: > > > blindfold wrote: > > > My understanding is that a flash cell normally contains one or (in > > > multilevel storage) two bits of data. Moreover, in my example I am > > > writing to every available bit, so the chunk size is irrelevant as > > > this leaves no room to spread the cell load over more cells through > > > wear-leveling algorithms, or "seamlessly change the mappings" as you > > > put it. Error correction codes and spare cells, if present, could > > > indeed help, but I have not heard that these are commonly applied in > > > the kinds of low-cost flash memory devices that we are talking about > > > here. > > > Um, no. > > > You can only erase flash in large chunks --- these are the cells. Each > > physical cell can only be erased so many times. Erasing a cell can take > > a very long time (like, a second). > > > The microcontroller keeps a mapping of what logical disk block is stored > > in which flash cell. When you ask the SD card to write to a particular > > logical block, the microcontroller will *pick a different cell*, one > > that it's already erased, and copy all the data from the old cell into > > it (with the changes you specify). Then it starts the erase process on > > the old cell in the background so that eventually the old cell will > > become empty and can be reused. > > > This means that if you write to the same *logical* block 10000 times, > > you're probably going to be writing to 10000 different cells once. So > > instead of using up all the erases in one cell, you've merely used up > > 1/10000th of the erases in 10000 cells. > > > Wear levelling is an extension of this which *ensures* that you're going > > to be writing to 10000 different cells, so keeping the overall wear > > constant across the device rather than being concentrated in particular > > cells --- very important when using file systems like FAT. > > > Here are some figures: > > > Assuming a 64kB cell size, which seems reasonable, a 1GB flash card will > > contain 16384 cells. Each cell can be erased 10000 times. (In fact, > > cheapo SD cards these days are more like a million.) This means that you > > can write to a cell 163840000 times on the card, approximately, before > > it dies of old age; this is about 10TB of writes. > > > Your sample application is MP3 streaming. Streaming at 128kbs will > > involve writing 16kB/sec which means you need to write a cell every 4 > > seconds. (And because it's a nice simple stream, buffering will ensure > > that you're only flushing a cell when necessary rather than having to > > write partial cells, which will of course use up your quota faster.) > > This means you get 163840000*4 = 655360000 seconds = 21 years of MP3 > > streaming before your SD card gives up the ghost. > > > You give a pathological example of a 128MB card that's 90% full. This > > means there are only 204 cells, which means only 2040000 writes, which > > comes to 8160000 seconds = 94 days. That's still a lot. In fact, you > > can't get 128MB SD cards any more; even when you could they used much > > smaller cell sizes; the SD card microcontroller keeps spare cells around > > for just this situation; and every time the user writes to one of the > > other 90%, it'll give the microcontroller the chance to rearrange the > > cells again, which means you'll get another 10000 or so writes, which > > gives you another 11 hours. > > > This really isn't a problem any more. Flash devices these days generally > > have longer lifetimes than hard disks. > > > (Although you *are* at the mercy of the SD card vendor's > > microcontroller. I've heard rumours of some bad SD cards where the > > microcontroller stored the whole wear map in a single cell --- which > > wasn't wear levelled. Yeah, like that's going to work. But in my entire > > career, I have met *one* person who has had a flash device die of old age.) --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Android Internals" group. To post to this group, send email to android-internals@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/android-internals?hl=en -~----------~----~----~----~------~----~------~--~---
