as a former audio engineer, I was surprised recently to see a unit like the Samson R16 for sale:
http://www.samsontech.com/products/productpage.cfm?prodID=2009 which uses an SD Card as its main memory. 8 track linear PCM audio record, 16 track playback. Of course, it's a case of several large files not lots of little ones... but it struck me that there must be some kind of SD r/w optimization in a unit like that. Sean. On Tue, Nov 17, 2009 at 6:39 PM, Adrian Chadd <[email protected]> wrote: > My experience with SD media in general (and I can't test it on XO > systems; I loaned mine out to other testers for the time being) is > that the performance is wildly varied. > > It probably doesn't help that the underlying IO is translating as > "read, erase, write" in some cases for lots of sub-flash-"chunk/page" > writes and how that is treated is highly device dependent. > > It may be a fun experiment (for values of "fun" that appeal to me at > least) to write some direct-to-device IO tests which experiment with > differing write and erase sizes. Say, try doing random writes of 1k > data in 1k offsets, in 2k offsets, in 4k offsets, etc. Then try 2k > data in the same offsets. See what changes. That may give you some > subtle hints as to what the SD controller is doing. > > This is why the idea of buffering IO and doing up a log structured FS > on the consumer flash devices is an interesting prospect, if difficult > to get right. You have this massive disconnect between read and write > IO times, you want to minimise the amount of writing you do but you > absolutely have no issue doing a whole lot of reads. > > The actual SSD devices as far as I can gather do a variety of magic to > try and drop the flash erase time from hurting write performance so > much. I cant comment there with any experimental or other authority. > > HTH, > > > Adrian > > (ObNote: I've been toying with small object cache stuff on commodity > flash media lately; the above is purely from experiences with that.) > > 2009/11/18 Daniel Drake <[email protected]>: >> Hi, >> >> Today I tried to figure out why running "sync" often takes 5-10 seconds >> or longer. This slows down suspend, where all data is synced to disk. >> In all cases that I looked at, the amount of data being synced was tiny. >> One example: in one run it had 160kB data to sync and it took 7.7 >> seconds. (blktrace is very handy for figuring this out) >> >> I traced this all the way to the SDHCI driver. These writes are >> typically small and scattered, and our hardware (or the card itself) >> takes a long time to process them. Many of the 1024 byte writes take >> 500-600ms. All other disk I/O is halted during these times. The delay is >> purely after submitting the SDHCI write command, and waiting for the >> completion interrupt to arrive. >> >> I then wrote a C application to reproduce the exact set of writes from a >> 20-second sync that I logged (using random data, but the same sectors, >> sizes and ordering) and reproduced the issue that way. >> >> I also moved the card over to my Dell laptop, ran the same program and >> saw the same (terrible) results. >> >> All info here: >> http://dev.laptop.org/ticket/9688 >> >> >> So, I have a feeling that at least with today's generation of miniSD >> cards we're going to be stuck with bad write performance, particularly >> for random-style access like this. >> >> One experiment that would be interesting to run would be to try this on >> one of the PhoenixBIOS boards, and then try it with the exact same SD >> card on a regular XO-1.5. Just in case... >> >> Daniel >> >> >> _______________________________________________ >> Devel mailing list >> [email protected] >> http://lists.laptop.org/listinfo/devel >> >> > _______________________________________________ > Devel mailing list > [email protected] > http://lists.laptop.org/listinfo/devel > _______________________________________________ Devel mailing list [email protected] http://lists.laptop.org/listinfo/devel
