How to Test the SD Card Speed on Your Raspberry Pi

Some of us will have multiple SD cards lying around. And sometimes it isn’t obvious which one is the best to use.

Here is how you can check the speed of your SD cards which may help you with choosing the fastest one.

hdparm is a good tool to view disks reads, from the disk and from the buffer. We will use two options for hdparm;

  1. The speed of reading directly from the Linux buffer cache without disk access. (-t option)
  2. The speed of reading through the buffer cache to the disk without any prior caching of data. (-T option)

The first shows us an indication of the throughput of the processor, cache, and memory of the system under test. The second measures how fast the drive can sustain sequential data reads, without any filesystem overhead. It is also best to run this command multiple times to see the affect of the caching.

 

Need to install hdparm, and then run it at least twice.
From my output below, you can see that the response for the cached reads increased the second time I ran hdparm.

pi@raspberrypi ~ $ sudo apt-get install hdparm
pi@raspberrypi ~ $
pi@raspberrypi ~ $ sudo hdparm -tT /dev/mmcblk0  /dev/mmcblk0:
Timing cached reads: 104 MB in 2.01 seconds = 51.67 MB/sec
Timing buffered disk reads: 58 MB in 3.03 seconds = 19.12 MB/sec
pi@raspberrypi ~ $ sudo hdparm -tT /dev/mmcblk0  /dev/mmcblk0:
Timing cached reads: 188 MB in 2.03 seconds = 92.76 MB/sec
Timing buffered disk reads: 60 MB in 3.03 seconds = 19.83 MB/sec
pi@raspberrypi ~ $

 

 

DD can also be used to test SD card speeds.
WARNING: you must be careful using DD as incorrect options can erase your SD card.

This command will write a 200MB file called test to the SD Card;
dd if=/dev/zero of=test bs=1048576 count=200

This command will read the 200MB file created in the first command;
dd if=test of=/dev/null bs=1048576

 

pi@raspberrypi ~ $ dd if=/dev/zero of=test bs=1048576 count=200
200+0 records in
200+0 records out
209715200 bytes (210 MB) copied, 9.6409 s, 21.8 MB/s
pi@raspberrypi ~ $
pi@raspberrypi ~ $ dd if=test of=/dev/null bs=1048576
200+0 records in
200+0 records out
209715200 bytes (210 MB) copied, 10.2369 s, 20.5 MB/s
pi@raspberrypi ~ $

 



 

5 thoughts on “How to Test the SD Card Speed on Your Raspberry Pi”

  1. Unfortunately it isn’t quite that simple. IMHO the “slow”, cheap cards turn out to be the fast ones—at least as far as devices like the Raspberry and Android phones are concerned. How’s that?

    Well, there is a huge difference between sequential and random access speeds. Both of your suggestions only test for sequential speed, which is important for digital cameras and so on. However, for use with the Raspberry, random access is much more important. Nowaday’s fast Class 10 cards achieve their high read and write speeds only by buffering in advance, assuming that the subsequent blocks will be read or written next. That means they inevitably sacrifice random read and write speeds. This effect is in the order of several magnitudes. For instance, a card with sequential read and write speeds of 10 MB/s might collapse to just 0.01 MB/s for random access. Therefore, Class 2 or Class 4 cards fit the Raspberry much better.

    CrystalDiskMark seems to be about the simplest way to reliably determine sequential as well as random read and write speeds, for small as well as big block sizes. See also:

    http://forums.whirlpool.net.au/forum-replies.cfm?t=1582172
    http://www.raspberrypi.org/phpBB3/viewtopic.php?f=2&t=4076

  2. There is a typo in the first window:
    pi@raspberrypi ~ $ sudo hdparm -tT /dev/mmcblk0/dev/mmcblk0:
    Timing cached reads: 104 MB in 2.01 seconds = 51.67 MB/sec
    Timing buffered disk reads: 58 MB in 3.03 seconds = 19.12 MB/sec

    it should be:
    pi@raspberrypi ~ $ sudo hdparm -tT /dev/mmcblk0
    /dev/mmcblk0:
    Timing cached reads: 104 MB in 2.01 seconds = 51.67 MB/sec
    Timing buffered disk reads: 58 MB in 3.03 seconds = 19.12 MB/sec

  3. Would this approach also find cards likely to fail at some point?
    Leave them copying the same file over and over, on the basis that eventually a failed sector should make its appearance.

Leave a Reply