XO-1.5 slow disk writes

[Sean DALY]

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 <adrian at squid-cache.org> 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 <dsd at laptop.org>:
>> 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
>> Devel at lists.laptop.org
>> http://lists.laptop.org/listinfo/devel
>>
>>
> _______________________________________________
> Devel mailing list
> Devel at lists.laptop.org
> http://lists.laptop.org/listinfo/devel
>