Raspberry Pi Overclocking Guide — Model 3B & 4B

Tech Workshop Single Board Computers
1

Practical overclocking notes for the Raspberry Pi 3 Model B and Pi 4 Model B. Both tested personally at TrojanHQ. No theory — just what works, what the parameters mean, and what to watch out for.

Important — Firmware Path Change (2025)

After firmware updates in 2025 the config file location changed.

Old path: /boot/config.txt Current path: /boot/firmware/config.txt

If you’re following older guides online and your changes aren’t taking effect — this is why. Edit the correct file.

Raspberry Pi 3 Model B

Specs Reference

  • 1.2GHz 64-bit quad-core ARMv8 CPU

  • 1GB RAM

  • VideoCore IV 3D graphics core

  • 802.11n Wireless LAN, Bluetooth 4.1 BLE

  • 4x USB, HDMI, Ethernet, 40 GPIO pins

  • Micro SD slot, CSI camera interface, DSI display interface

TrojanHQ Tested Config

ini

arm_freq=1350
core_freq=500
over_voltage=4
gpu_mem=100
disable_splash=1
# force_turbo=1        # Voids warranty — uncomment to prevent CPU scaling to 600MHz
# boot_delay=1         # Helps avoid SD card corruption if force_turbo is enabled
# sdram_freq=500       # Uncomment to test — works only on some boards

Personal notes:

  • Running stable at 1350MHz with Trojan thermal paste, dual fan and heatsink mounted to GPIO

  • GPU memory set to 100MB — adequate for headless and most light desktop use

  • Over voltage at 4 — stable, no issues

  • force_turbo left commented — not needed for application use, dynamic clocking handles it fine

  • Warranty void flag only trips if you uncomment force_turbo or push over_voltage above 6

Parameter Reference

Parameter Description
arm_freq ARM CPU frequency in MHz
core_freq GPU core frequency in MHz — also drives L2 cache, affects ARM performance
sdram_freq SDRAM frequency in MHz — board dependent, test carefully
over_voltage ARM/GPU core voltage adjustment — values above 6 require force_turbo and void warranty
force_turbo Disables dynamic cpufreq scaling — CPU runs at max clock permanently — voids warranty
initial_turbo Enables turbo from boot for up to 60 seconds, or until cpufreq sets frequency
arm_freq_min Minimum ARM frequency for dynamic clocking
core_freq_min Minimum GPU core frequency for dynamic clocking
sdram_freq_min Minimum SDRAM frequency for dynamic clocking
temp_limit Overheat protection threshold in °C — triggers clock and voltage reset at this temp. Default 85°C. Raising it voids warranty
disable_splash Set to 1 to skip the rainbow splash screen on boot
boot_delay Seconds to wait before loading kernel — use with force_turbo to prevent SD corruption
gpu_mem GPU memory split in MB — ARM gets remainder of total RAM

Cooling Requirements

At 1350MHz with over_voltage=4 — active cooling is not optional. The Pi 3B will throttle without it under sustained load.

Minimum: heatsink on the SoC and any secondary chips. Recommended: heatsink plus small fan. TrojanHQ runs dual fan and heatsink mounted directly to GPIO pins for power — clean solution, no USB port used, runs on 3.3V or 5V GPIO depending on fan spec.

Raspberry Pi 4 Model B

Quick Config Reference

ini

# Force 1080p output on 4K TV
hdmi_group=1
hdmi_mode=16

# Remove black border lines on non-native resolution screens
disable_overscan=1

Config file location (post-2025 firmware):

/boot/firmware/config.txt

Pi 4 Overclocking Notes

The Pi 4 handles overclocking more gracefully than the Pi 3 thanks to improved thermal design and the more capable BCM2711 SoC. Stable overclock headroom exists at the CPU and GPU level without aggressive voltage adjustments.

Full Pi 4 overclock config and tested settings to follow in a dedicated thread as testing continues.

General Pi Notes

SD card matters more than most people realise. A fast SD card has more impact on perceived performance than a mild overclock. Class 10 minimum. A1 rated cards (random read/write optimised) make a significant difference for OS operations. If your Pi feels sluggish and you haven’t tried a better SD card — do that before touching the overclock.

Temperature monitoring during testing:

bash

vcgencmd measure_temp

Run this during load to verify temps before committing to a config. Anything consistently over 80°C under load needs better cooling before pushing further.

Check current clock speeds:

bash

vcgencmd measure_clock arm
vcgencmd measure_clock core

Check throttling status:

bash

vcgencmd get_throttled

Returns 0x0 if clean. Any other value indicates throttling has occurred — back off clock or improve cooling before proceeding.

Use Cases at TrojanHQ

The TrojanHQ fleet runs two Raspberry Pi units in active production roles:

  • Monitoring node — Grafana dashboard, system health, temperature and status reporting across the fleet

  • Automation node — scheduled tasks, lightweight scripting, network utilities

Grafana specifically benefits from the overclock. It is not a lightweight workload. Grafana is continuously pulling metrics, running queries against a database, and rendering dashboards. On a Pi 3B at stock 1.2GHz this is sluggish and noticeable. At 1350MHz with over_voltage=4 and proper active cooling — it runs properly. The overclock config above was developed and tested for exactly this use case.

If your Pi is running anything that involves a web interface, a database, or continuous data processing — the overclock is worth doing. Stock clocks are fine for simple scripts and GPIO work. Anything serving a dashboard or running queries deserves the headroom.

Run From SSD — Not SD Card

For any Pi running production workloads — Grafana, Home Assistant, monitoring, anything writing data continuously — boot from a USB SSD, not an SD card.

SD cards are not designed for the continuous read/write cycles that a production workload generates. They will corrupt. It’s not a question of if — it’s when. A Pi running Grafana writing metrics every few seconds will kill a cheap SD card within months.

A USB SSD costs under $30 AUD. The Transcend USB adapter solution works cleanly — SSD in a USB enclosure, Pi configured to boot from USB, done. Faster than any SD card, orders of magnitude more reliable for write-heavy workloads, and when it eventually needs replacing it’s a $30 fix not a corrupted SD rebuild.

To enable USB boot on Pi 3B:

bash

echo program_usb_boot_mode=1 | sudo tee -a /boot/config.txt
sudo reboot

Verify USB boot is enabled after reboot:

bash

vcgencmd otp_dump | grep 17

Should return 17:3020000a — USB boot enabled.

Then clone your SD card to the SSD, plug in the USB SSD, remove the SD card, boot. The Pi will boot from USB automatically once the fuse is set.

Power — The Thing That Kills More Pis Than Anything Else

This cannot be overstated. A Pi running on inadequate power is not a Pi running — it’s a Pi waiting to fail.

Use a genuine or solid-brand power supply rated correctly for the Pi model. The official Raspberry Pi adapter is the benchmark. Equivalent quality from a known brand works. A random USB charger that claims the right output and doesn’t deliver it under load will undervoltage your Pi mid-operation and corrupt your SD card or SSD at the worst possible moment.

The lightning bolt icon in the top right of the desktop is the undervoltage warning. If you see it — the power supply is the problem. Full stop. Fix it before anything else.

Quality battery packs are a legitimate option for portable or backup-power Pi setups — provided they output the correct wattage and maintain stable voltage under load. Not all power banks are equal. Check the actual sustained output rating, not the headline capacity number. A 20,000mAh bank that can only sustain 10W output is not suitable for a Pi 4 under load. One that maintains stable 15W+ is. The Pi running on a quality battery pack that handles momentary power outages and keeps the system live is a legitimate and well-tested configuration.

The 200+ day uptime test: The TrojanHQ Pi 4 monitoring node recently came through a power outage after 200+ days of continuous uptime. Power restored, system came straight back up, continued running without intervention. That’s not luck — that’s correct power hardware, SSD boot instead of SD card, stable overclock with thermal headroom, and quality components throughout. Every one of those decisions contributed to that outcome.

PiHole — The “It Doesn’t Need The Power” Argument

PiHole is one of the most common Pi use cases and it generates the most debate about whether overclocking is necessary.

The argument against: PiHole is just DNS filtering. It’s not computationally demanding. Stock clocks handle it fine.

That argument is technically correct and practically incomplete.

You’re not overclocking PiHole because it’s struggling to process DNS requests. You’re overclocking because a DNS sinkhole handling every DNS request on your network going down for 30 seconds takes your entire network with it. Every device that relies on it for DNS resolution stalls. Browsing stops. Services that phone home get confused. The network degrades until DNS recovers.

The overclock isn’t buying you performance headroom on PiHole. It’s buying you stability margin — ensuring the system stays responsive under any combination of simultaneous requests, background tasks, and system operations without thermal throttling or resource contention causing hiccups.

TrojanHQ runs PiHole in a VM for the primary infrastructure and on a Pi 4 as well. The Pi 4 runs overclocked. Not because PiHole exhausts it — it doesn’t, even overclocked the headroom is significant. Because a system that critical running with margin is always preferable to one running at its limits.

200+ days. Power outage. Straight back up. The overclock contributed to that reliability, not away from it.

:crossed_swords: King Frost — TrojanHQ

More SBC content coming: Pi 4 full overclock guide, GPIO projects, and the N100/N150 mini PC as a step up from SBC for more demanding home lab workloads.