How to overclock the microSD card reader on a Raspberry Pi 3

Late last year, I published a blog post with comprehensive benchmarks of various microSD cards used with the internal Raspberry Pi 2 reader, based on the comprehensive (and always-up-to-date Raspberry Pi microSD card benchmark page I maintain for the Pi Dramble project). After publishing the blog post, a few different readers pointed me to some overclocking tweaks that could help boost the speeds further for UHS microSD cards, allowing large file I/O speed to double, and random I/O to get a solid boost as well.

I finally got my hands on a Raspberry Pi 3 and wanted to see how it compares to the Pi 2 (review + benchmarks incoming!), but one of the first things I wanted to test was overclocking the microSD clock for better disk I/O. On average, with all the cards I've tested so far, overclocking the microSD reader resulted in 25-50% better performance for real-world disk operations (benchmarks further down in this post). And with a reliable power supply, you shouldn't need to worry about reliability or corruption (in my limited stress testing, I only had one corruption, and that was when I was using my cheaper iClever power supply).

Overclock the microSD reader with sdhost

First, a caveat: I generally treat my Pis as cattle, not pets, so I do crazy things to them on an hourly basis, and typically rewrite the microSD cards dozens of times trying new configurations, building new servers, etc. If you have anything important on your Pi, overclocking the reader can cause data corruption, especially for non-UHS-certified cards. Make a backup! You've been warned!

Add a dtoverlay directive to overclock the microSD reader to 100 MHz (it defaults to 50):

sudo bash -c 'printf "dtoverlay=sdhost,overclock_50=100\n" >> /boot/config.txt'

Reboot the Raspberry Pi (sudo reboot), and you should experience much better disk I/O!

Note: The above instructions work on the Raspberry Pi 2 and other models as well (assuming you use a valid integer divisor of the core clock—on the Pi 2 you could try 84, 72, or 63 by default).

Benchmarking microSD cards

There are a couple benchmark scripts you can run to test the speed and verify the updated microSD clock:

# Installs and run hdparm, dd, and iozone benchmarks.
$ curl | sudo bash

# Run hdparm and some large file read/write benchmarks.
$ curl | sudo bash

Here are a couple quick benchmarks comparing the same cards at normal clock and overclocked:

Raspberry Pi 3 microSD card performance - overclock with sdhost

Random disk I/O performance has the highest impact on most day-to-day Pi usage (especially if you use it as a desktop computer!), so I tend to focus my benchmarking on it; large file operations (e.g. large file reads and writes) basically doubles with the 2x clock speed increase, so if you do things like copy giant files across the network or stream large video files, then the performance boost may be even more noticable. 4K random writes don't benefit as much, mostly because microSD cards typically max out at much lower speeds than would saturate the Pi's bus.

Potential issues

If you notice the clock is not set at 100 MHz after changing these settings (both of the above benchmark scripts output the current clock setting before running the benchmarks), and you've confirmed the steps above were run correctly, there are two things that could be causing problems:

  • If your power supply can't supply at least 2.4A at a consistent 5V, then the Pi might not even boot, or might automatically under clock the SD reader.
  • If you run dmesg after bootup, see if there are any messages relating to mmc0 and "reducing overclock"; the card might not be able to sustain a full 100 MHz overclock.

Sometimes a simple hard power off and power on will resolve these issues; other times it just means either your card, your Pi, or your power supply won't sustain the overclock setting reliably. You can try other, lower overclock settings, as long as the number is an integer divisor of the core clock (default is 400 MHz on the Pi 3), e.g. 50, 80, or 100.

Also, if you experience WiFi issues, or if your Raspbian version doesn't include the sdhost overlay inside /boot/overlays, you can download sdtweak-overlay.dtb manually: sudo wget -O /boot/overlays/sdtweak-overlay.dtb; it's better to update/upgrade, though, so the sdhost overlay is present. You will also need to change 'sdtweak' to 'sdhost' in the overlay line in config.txt if you do this.

More info


I'm reposting a snippet from a comment from this post's Reddit thread, from user QuirkyQuarQ:

tl;dr: All UHS-I cards should be capable of up to 100 MHz, but YMMV. How high depends largely on the card, not the Pi.

By default, the Pi provides 50 MHz as the SD clock.This is technically the maximum for non-UHS cards ("SD mode") according to the SD specification, and since SD cards perform I/O in 4-bits (0.5 bytes)-per-clock-cycle, should result in a theoretical max transfer rate of 25 MBytes/sec (about 21-22 in the real world after overhead, etc.) Non-UHS cards (i.e. no "I" or "U1" logo on the card) are not required to go higher than 50 MHz.

UHS-I microSD cards, on the other hand, must support up to 100 MHz in UHS mode. Although the Broadcom SoC is capable of UHS mode, the Pi does not support it because it requires 1.8v signaling while the Pi's is fixed at 3.3v.

I'm going to see if I can push some of my UHS-3-certified cards to even higher clocks as QuirkyQuarQ suggests later in his post, and update this post with results...

For more information on UHS/Class certifications for SD cards, see this page:

After a few more tests with higher clock rates (133, 150, 200), nothing ended up working (these settings resulted in different amounts of errors or gibberish during boot).

All 3 of my 64gb evos (non+) are able to handle 107mhz. As expected, 4k performance isn't noticeably affected, but sequential read goes up proportionately.

There is an easier, better way to overclock the UHS-1/HC-1sdcard on the Pi3, and benchmark it using 'sdbench'.

sudo apt-get update
sudo apt-get dist-upgrade
sudo apt-get install piclone geany usb-modeswitch pi-bluetooth
sudo apt-get install python-pigpio python3-pigpio mesa-utils
sudo reboot

sudo nano /boot/config.txt


open, select/copy all:

open, paste into:
sudo nano


then make it executable:
sudo chmod +x

run benchmark:
sudo ./

Does this void the Raspberry Pi 3's warranty bit? Just want to make sure before proceeding.


sudo bash -c 'printf "dtparam=sd_overclock=100\n" >> /boot/config.txt’

You can edit file containing these settings with:

sudo nano /boot/config.txt

when I run the second test "curl | sudo bash" on my overclocked SD reader I get these results on my large file read/write portion:

awk: cmd. line:1: (FILENAME=- FNR=1) fatal: division by zero attempted
536870912 bytes (537 MB, 512 MiB) copied, 23.1126 s, 23.2 MB/s
awk: cmd. line:1: (FILENAME=- FNR=1) fatal: division by zero attempted
536870912 bytes (537 MB, 512 MiB) copied, 14.8544 s, 36.1 MB/s
Overlay config                      core_freq   turbo   overclock_50    WRITE        READ        HDPARM
                                       500        0     100.000 MHz    0.00 MB/s    0.00 MB/s   33.81 MB/s

I don't know how to interpret those results since these error messages still produce some large read /write results

Even when I change the config.txt file back to the default clock speed for the SD card reader I still see these results:

CLOCK : 50.000 MHz
CORE  : 500 MHz, turbo=0
DATA  : 512 MB, /home/sandiskextreme/test.dat
Timing O_DIRECT disk reads:  66 MB in  3.00 seconds =  21.98 MB/sec
Timing O_DIRECT disk reads:  68 MB in  3.09 seconds =  22.02 MB/sec
Timing O_DIRECT disk reads:  66 MB in  3.02 seconds =  21.88 MB/sec
awk: cmd. line:1: (FILENAME=- FNR=1) fatal: division by zero attempted
536870912 bytes (537 MB, 512 MiB) copied, 26.8754 s, 20.0 MB/s
awk: cmd. line:1: (FILENAME=- FNR=1) fatal: division by zero attempted
536870912 bytes (537 MB, 512 MiB) copied, 26.8728 s, 20.0 MB/s
awk: cmd. line:1: (FILENAME=- FNR=1) fatal: division by zero attempted
536870912 bytes (537 MB, 512 MiB) copied, 27.0791 s, 19.8 MB/s
awk: cmd. line:1: (FILENAME=- FNR=1) fatal: division by zero attempted
536870912 bytes (537 MB, 512 MiB) copied, 23.4652 s, 22.9 MB/s
awk: cmd. line:1: (FILENAME=- FNR=1) fatal: division by zero attempted
536870912 bytes (537 MB, 512 MiB) copied, 23.472 s, 22.9 MB/s
awk: cmd. line:1: (FILENAME=- FNR=1) fatal: division by zero attempted
536870912 bytes (537 MB, 512 MiB) copied, 23.4881 s, 22.9 MB/s
Overlay config                      core_freq   turbo   overclock_50    WRITE        READ        HDPARM
                                       500        0      50.000 MHz    0.00 MB/s    0.00 MB/s   21.95 MB/s

I can't vouch for the sdbench script, since I didn't set up or maintain it (it seems like there's a command in there that's not compatible with the current release of Raspbian), but have you tried:

curl | sudo bash

Yes, your test ran ok with all my cards tested including the 16GB Sandisk Extreme that the other test battery was displaying the errors. When I ran the other test with some of my other cards, Samsung, PNY, Sony, etc., most ran ok, but a few also shown those "fatal" errors.

Makes more sense that there must be some issue with the SD card being used during the test. That was what I was trying to determine, if there was a known issue that others had experienced with certain SD cards. Thanks for your quick response.

I just tried this with a Lexar 633x 16Gb card in a Raspberry Pi 3. Wrote Raspbian. Booted. Made the change. Rebooted - failed.

Yeah, sadly sometimes cards don't work overclocked (though usually Lexar cards are pretty good at it).

The only other possibility is the boot parameters might have a syntax error, which would throw the Pi for a loop.

Hi Jeff,

Just bought some Samsung Pro Plus 32GB cards to try the overclock but if I go higher than 80 (100) it won't boot and it will give me a lot of errors at boot. Why?

Mine locks up on boot with anything over 100mhz for the overclock, but even at 100mhz I only get an actual clock of 87.5mhz.
In my opinion I reached the limits of the board or the SD card. (I am going to guess the board since my Pi3 is overclocked and my core is 525mhz now).

I have like this problem too. Sdcard Samsung Evo+ 32G, rp3, Raspbian Strech. When I set overclock to 100 and run write test:
sudo dd if=/dev/zero of=/home/pi/zero bs=1M count=300
My system is frozen and can't fork any process.

Samsung EVO+ 32GB ob RPI3 bought last week does not boot with overclock_50=100, fine with overclock_50=80

When I overclock my Pi 3B+ I got the following in sdbench:
CLOCK : 83.333 MHz
CORE : 250 MHz, turbo=0

Is the core clock of 250 correct?
Even when I set core_freq in config.txt to 500 it will stay at 250. Do I have to use other settings?


Let me inform you that in version 9.58 of hdparm the following command

pi@raspberrypi:~ $ sudo hdparm -t /dev/mmcblk0

gives the following message

HDIO_DRIVE_CMD(identify) failed: Invalid argument
Timing buffered disk reads: 68 MB in 3.08 seconds = 22.09 MB/sec

and in 9.51 and 9.56 it doesn't


Have you tried overclocking SD on the Pi 4 yet? I tried a number of these and still see 50MHz when I run sdbench or cat /sys/kernel/debug/mmc0/ios

I have WiFi issues, and the supplied command to fix them doesn't work, how can I fix it?

Adding the dtoverlay command KILLS wifi on my Pi 3B with Bullseye. The symptoms are no wifi, and ifconfig does not show a wlan0 device. After a lot of configuration and experimentation, I found that I just can't use your suggested dtoverlay command without losing wifi.
However, anyone with a Pi 3B who does not need wifi will get a generous speed improvement by using the dtoverlay command.

The Pi 5 appears to dynamically change the SD card bus speed depending on the SD card that's inserted. For example, my new SanDisk Extreme Pro card causes the Pi 5 to set the timing spec to 6: (sd uhs SDR104) and the clock to 200mhz. Is it still possible to increase that number? SanDisk claims this card should be able to manage 200 MB/s, which is almost twice as much as 104 MB/s, so it seems there could be some headroom there if the card is of high enough quality.