Why is my SD card slow?

Question

My SD card seems to be running slow. I have an ADATA 16 GB SDHC Class 10 card. I checked the compatibility list which lists a card with similar specifications, and it states that it is "working". Even simple tasks like getting a directory listing on a small directory can take a few seconds the first time I request it. Are there any tools I can use to verify what kind of performance I'm getting out of my SD card? Also, are there any configuration changes I can make to get the SD card to respond faster?

I'm using the Raspberry Pi as a headless BitTorrent seedbox, so all the stuff I'm running into is just running on the command line. I'm using the 240/16 split to ensure that I have the maximum amount of memory available.

Updates

After running some tests as @Krzysztof Adamski recommended with "dd", I received some good results getting a read speed of 20 MB/s and a write speed of about 10 MB/s. However, it still seem to be having some I/O speed issues. When testing, I ran the "dd" commands in the background, and ran top, to see what was going on. I noticed that the "mmcqd" process was taking up quite a bit of processor usage, between 5% and 10%. I looked around on the Internet and found many instances of people reporting that "mmcqd" uses up quite a bit of the CPU. I then ran the following command to test reading and writing at the same time

sudo dd if=/dev/mmcblk0 of=test.dat bs=1M count=1024

When running this command I got a throughput of only 977 kB/s, and "mmcqd" reported processor usage between 10% and 25% every 5 to 10 seconds, after which it would go back down to nothing. So, I did some more testing. I ran the following two commands in the background, and then watch what was going in top.

sudo dd if=/dev/mmcblk0 of=/dev/null bs=1M count=1024 &
sudo dd if=/dev/zero of=test.dat bs=1M count=1024 &

In this case "mmcqd" would peak around 35% processor usage, but the throughput was a lot better at around 7.5 MB/s for reading and around 5.3 MB/s for writing.

It seems that there is some kind of problem going on here where heavy writes cause the "mmcqd" to lock up the system. This causes transmission-daemon to slow down to almost zero as soon as it the speed gets too high as it waits for the SD card. When running transmission-daemon I also see the "mmcqd" usage get quite high.

Answer 1

Testing card read speed:

There are two easy ways to test read speed (listing directory is only a read operation):

• using dd command:

  sudo dd if=/dev/mmcblk0 of=/dev/null bs=8M count=100

  This will read 800MB of data from your SD card and discard this to /dev/null. If it takes to much time, you can change count=100 to count=10 to only read 80MB. After command finished it should print a message with read speed. You should get at least couple MB/s.

• using hdparm command:

  sudo hdparm -t /dev/mmcblk0

  This should give you similar speed result as the first command and should also be at least couple of MB/s.

Testing card write speed:

There is no easy way of testing write speed as to do this you would have to actually write some data to the card. If you would like to do this on low level (omiting filesystem) you would have to override some data on the card and you probably don't want to do this. This can be done if you have swap partition as it can be easily deactivated (with swapoff -a), tested with dd (with dd if=/dev/zero of=/dev/{yourswappartitionnanehare} bs=8M count=25) and then recreated (with mkswap /dev/{yourswappartitionnanehare}).

If you don't have swap partition, you can test filesystem write speed also using dd command:

dd if=/dev/zero of=/home/pi/testfile bs=8M count=25

This will create 200MB file in /home/pi/testfile. You can use any other filename you want.

Notes:

• While testing speed, ensure no other programs are running in your system (like torrent application etc).
• After testing, you can check the output of dmesg command to see if there are any messages about mmc subsystem.
• Ensure you have most up to date firmware installed. There are patches regardless SD card speed from time to time.
• You may also want to check some older firmwares since there may be some regressions. The easiest way to do this (but not the best) is to test different system images that where build on different dates. The harder way is to use github and checkout historical versions of firmware files.

Answer 2

For SD card performance it matters a lot whether the access is sequential (as with dd) or random access in small blocks. SD cards, especially those of high class seem to be optimized for sequential access, which is good for storing photographs or video. However, for running an OS of the SD card random access is more important, since lots of small files are read and written. I would guess bittorrent generates somewhat random accesses as well.

These two discussion threads contain a lot of SD card benchmarks and discussions. In general, the random write speed was found to be decisive for the responsiveness of running an OS of the card. This speed is frequently much lower than the speed of sequential writes, which is the speed the manufacturers like to report. The SD card class is based on sequential speeds, and lower classes (4 or 6) may in fact be more suited for raspberry use.

The iozone tool measures the speed of many different access patterns. I have posted brief instructions for compiling iozone on the raspberry here.

Answer 3

The maximum speed of the RaspberriPi SD card bus provides a hard speed limit. According to discussions online, the maximum bus speed is ~23MB/s. That provides a hard limit to SD read/write speed in addition to the sequential/random read/write issues noted by other users.

Answer 4

For the RasPI onboard slot there is a huge discussion on the RasPI site: http://www.raspberrypi.org/phpBB3/viewtopic.php?f=63&t=5057&sid=ee346e3e7cea48d2858a143bcf086362

Didn't got the time to read all through the 12 pages of discussion, but it seems to be a problem with the CLK signal.

Answer 5

You write "bittorrent" and that triggers my guess/answer.

The torrent protocol receives packages in random order from random seeders.

Once you start to use torrent on any filesystem, it becomes rather fragmented. This will hurt performance bigtime.

From what I know about the SDCARD, its running FAT/FAT32 and thas even worse for handling fragmentation.

So find a way to defragment your SDCARD, or copy all the files away from it and then reinstall the OS.

Lastly, writing a LOT (as the bittorrent engine will) will tear your SDCARD more quickly than normal usage. I dont say thats its wrong to do it, infact I had considered to to similar myself. But - that might be the reason for your problem.

I wish there was a torrent client that automatically would transfer/move the downloaded files to a whole other destination once the download + "reserved upload time" was completed.

Then the defragmenting would go a lot faster.