27

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.

Peter Mortensen
  • 2,004
  • 2
  • 15
  • 18
Kibbee
  • 1,102
  • 3
  • 11
  • 15
  • Are you sure that SD card causes this problem? Could you first try to use another card to exclude another parts of system? – David Ferenczy Rogožan Aug 23 '12 at 01:27
  • Have you checked you syslog and kernel log for messages related to the mmc device? Some cards simply does not work in the Raspberry Pi. Some others requires a bit of tweaking to work reliably. – Joppe Oct 25 '12 at 13:50
  • SD card link has moved – ray023 Feb 16 '13 at 18:30
  • 1
    @Ray023 Thanks. I updated the link. In the future, you can just edit the question. I think because you are new, the edit won't be taken right away, but will be saved for the original poster or some other high rep user to approve. – Kibbee Feb 17 '13 at 17:47

5 Answers5

22

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.
Krzysztof Adamski
  • 9,615
  • 1
  • 37
  • 53
  • My compliments. On a MacBook Air I got 1.4 MB / sec when writing out an img file to a class 6 4GB SD Card. A read test on the PI reported 20 MB / second!? – ScrollerBlaster Oct 15 '12 at 22:23
  • I have the same thing. My read speed is something like 500MB/sec. I'm I get something wrong? – Darkest N2O Nov 27 '17 at 14:59
12

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.

Frepa
  • 2,261
  • 19
  • 17
  • 2
    Interesting answer. Nice one. – Jivings Oct 24 '12 at 05:29
  • very interesting as I just bought 4x class 10... dang! :-( – BerggreenDK Feb 28 '13 at 09:09
  • @BerggreenDK: Maybe in the future you well use the cards for a different purpose and then maybe you will be happy that you bought class 10 cards. – Neverland Jun 27 '15 at 18:24
  • 1
    Random write speed should have little effect in typical tasks like boot sequence or directory listing. Even for torrents, test results with 4KB writes are irrelevant: typical chunk sizes are around 1MB, and unless you have no free RAM, disk cache will group these into even bigger sequential writes. – Dmitry Grigoryev Feb 08 '17 at 11:48
0

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.

user1847
  • 101
  • 1
0

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.

Mose
  • 661
  • 5
  • 12
0

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.

BerggreenDK
  • 364
  • 1
  • 3
  • 14
  • How does fragmentation apply to SD Cards? I thought fragmentation was only a problem on spinning disks, because the file would be located on non-sequential sectors, causing the read/write head to have to move all over the place to access a file. On solid state storage such as SD cards, this is a non-issue. However, I will agree with you about the number of write actions caused by bittorrent. I think that has alot to do with the problem. Combine that with the small amount of memory on the RPi (mine has 256 MB) and it seems to be a recipe for slow disk access. Also SD cards are slow in general. – Kibbee Feb 27 '13 at 13:28
  • Well, the FAT/FAT32 structure is bad and slow once you start to have many fragments of files. And the little Raspberry doesnt have too much power to move around with. So anything that comes in its way, slows it down. But again, its just my guess. I have no facts on this. – BerggreenDK Feb 27 '13 at 23:20
  • 1
    The RPi doesn't even use FAT/FAT32. The file system is EXT4. – Kibbee Feb 28 '13 at 00:35
  • Really? well, I thought I read FAT on my SDCARD. Hmmm... perhaps my answer needs to be completely removed then? – BerggreenDK Feb 28 '13 at 09:08
  • 3
    The answer has a good point in that bittorrent probably writes data to files in small pieces in random order. This type of random write is very inefficient on SD cards. But I don't think defragmenting would help. Actually, FAT is used on the Pi, but only for the boot partition. – Frepa Feb 28 '13 at 09:28
  • Ahhh, so THATS why I thought it was FAT. Pheeww.. thought I was going blind. – BerggreenDK Feb 28 '13 at 09:31
  • I would... create a seperate partion or use an external HDD for torrents if I had the same problem – BerggreenDK Feb 28 '13 at 09:31
  • 1
    @Kibbee: See my answer at http://raspberrypi.stackexchange.com/questions/8850/finding-cards-optimized-for-random-read-write/9174#9174 to understand why SD cards have fragmentation issues of their own. Many software techniques which would avoid physical disk fragmentation (such as pre-allocating files) are useless with SD cards, since sectors are placed (or moved) when data is written to them, rather than when they're allocated. – supercat Aug 23 '13 at 15:02