Breaking Eggs And Making Omelettes

Topics On Multimedia Technology and Reverse Engineering


Archives:

SD And Me

November 20th, 2008 by Multimedia Mike

When I got my Eee PC last December, I was exposed to 2 computer things I had never dealt with before: wireless networking and SD memory (yeah, I’m behind the curve technologically; what of it?). The Eee PC — at least the 701 — is not outfitted with a great deal of storage, only 4 GB SSD. An easy way to expand the capacity is to add an SD card. I did my homework on the technology because I saw that there were varying prices among many brands. Plus, they all seemed to be rated using an “X” speed. It turns out that this speed is the same as for compact discs (X = 150 kilobytes/sec, the minimum speed needed to play an audio CD).

I settled on a 133X PNY brand 2GB SD card for my Eee PC. The Xandros-based OS recognized it right away and it seemed to work just fine… except for one minor detail– its write speed was mind-bogglingly slow, about 350 kilobytes/sec, so about 2.5X. The read speed was fine, though. I clocked it in the range of at least 120X. This colored my perception of SD cards for much of this year — really fast to read and ludicrously slow to write — and I mainly used the SD card for storing large multimedia samples and other data that didn’t need to change often. I wondered how SD could be so widely used with such an abysmal write speed. It seems to be quite popular with cameras. I decided maybe that’s why cameras pack absurd amounts of RAM– to cache pictures until they can finally be dumped to storage. I asked other people about their experiences with SD memory but no one had thought to profile the stuff. Maybe they were fine with the slow write speeds?

I just bought a new digital camera and a 150X Transcend brand 2GB SD card. I couldn’t get the card to work in my camera (though the piddly 32 MB card included with the camera works fine). Before I returned the card, I decided to try it in my Eee PC. It worked pretty handily in there, so I proceeded to copy the data off of the PNY card and onto the Transcend card so I can perhaps use the PNY card in the camera. Large files were being written to the Transcend card in no time and so I profiled it a little more carefully. I saw write speeds of over 7 MB/sec. Okay, so this card definitely gets to live in my Eee PC.

But do I really want to put this slow PNY card in my camera? I decided to try the PNY one last time in the Eee PC. Suddenly, I saw outrageously high (compared to before) write speeds on the PNY. What’s going on?

One thing has changed in the interim: I have moved from using the Xandros-based Eee PC Linux to using Ubuntu-Eee. The only explanation I have at this point based on the available data is that the original OS had a really substandard SD card driver.

What have I learned from this exercise? I don’t know, maybe that I shouldn’t have such low expectations. If anyone cares about my precise methodology:

 # create a file of random garbage that is roughly 768 MB large
 $ dd if=/dev/urandom of=randomfile bs=1024 count=768000
 # this Eee PC has 512 MB of RAM; the file will not be cached in RAM
 $ dd if=randomfile of=sdcard/randomfile

The SD cards are formatted with ext2. This methodology is a little different than the one I found on ossguy’s blog where he profiled by reading and writing raw sectors. He did an undeniably thorough job, though, testing 5 cards against 3 different interfaces.

Posted in General | 5 Comments »

5 Responses

  1. Reimar Says:

    Hm, since there were no others available where I looked I bought a so-called SDHC card which was designed for camcorders, they can hardly give really bad write performance and indeed I get about 4 MB/s writing to a ext2 filesystem.
    I should note that I always set noatime in fstab, because I have no use at all for recorded last-access-times.
    I have one little “problem” though, it seems it is not possible to auto-mount the SD card in some specifice place via an fstab entry, very curious (does the SD interface driver get loaded after fstab is already processed?).

  2. Mart Says:

    Was it because the card was mounted “sync” in the first test, and “async” in the second test?

  3. Reimar Says:

    That is a good point, that comment
    # this Eee PC has 512 MB of RAM; the file will not be cached in RAM
    is not right, it means that at most 512 MB will be cached, so that can result in 3x as large values as correct (in theory, more like 1.5x probably in reality), so you should add a “sync” at the end.
    I didn’t make that error though since I was transfering a 3 GB file via ssh, and I got sustained write speeds of ca. 4 MB/s.
    And the “sync” mount option… the homage to users too “stupid” to unmount first…

  4. Mans Says:

    In addition to being slow, mounting flash cards with the sync
    option has the potential to destroy them really quickly. Sync
    tells the OS to flush all data and metadata for the file after
    *every* write() call. This means the file’s inode (or the FAT
    in case of (V)FAT filesystems) is updated millions of times
    when writing a large file. Even the most clever of wear levelling
    algorithms will struggle under such conditions. One of the
    primary uses for SD cards is in digital cameras, so a reasonable
    guess is that the wear levelling is optimised for such usage
    patters, i.e. files are 1-10MB, and the metadata is updated only
    after the file has been entirely written (my guess).

  5. Multimedia Mike Says:

    It sounds like there are some good angles to test, like the noatime setting. I still wonder why the Eee PC’s default configuration would be so suboptimal. But this might have been an oversight.