Overclocking the Raspberry Pi
I've been enjoying watching videos on my Raspberry Pi since I bought it last October, but it sometimes struggles a little bit with HD video, which is really annoying when it's in the middle of an important scene and the audio skips just enough to make me miss something. I decided I'd try overclocking the thing and see how much more performance I could get out of it.
I have Raspbmc installed on my Pi at the moment and I quite like it. By default it overclocks the CPU from its default 700 MHz to 800 MHz, which the Raspberry Pi people say is safe. The firmware loads the clock speed and chip voltages from /boot/config.txt, so this is where I'll be making all of the changes to overclock it. I've already made a few modifications to this file, but this is what it looks like before any overclocking:
arm_freq=800
gpu_mem=184
disable_overscan=1
start_file=start_x.elf
fixup_file=fixup_x.dat
There are quite a few parameters that can be set in this file, but the relevant ones are arm_freq, which sets the frequency of the CPU clock in MHz; gpu_freq, which sets the GPU's frequency in MHz; force_turbo, which, when enabled, disables CPU frequency scaling and allows higher levels of over voltage; and over_voltage, which sets the voltage of the CPU and GPU cores in 25 mV steps (plus the base 1.2 V).
The gpu_freq parameter is interesting because it's actually three parameters: core_freq, the frequency of the GPU core (this also determines the L2 cache speed and so also affects CPU performance); h264_freq, the frequency of the hardware video decoder; and isp_freq, the frequency of the Image Sensor Pipeline (used for cameras — up to 20 MP at 220 MP/s apparently). If gpu_freq does start causing stability problems, I may adjust these parameters independently but I don't want to bother if I don't have to.
Testing Method
I'll be testing configurations using a 1080p version of Blender's Big Buck Bunny (download .mkv). It's ~6300 kb/s H.264 with AAC audio so it should show any performance problems if they're present. I'll also be running the GNUPG benchmark from the Phoronix Test Suite for a more objective measure of the CPU's performance.
All of the tests will be run with force_turbo set to 1. This will disable the CPU frequency scaling so that it always runs at maximum speed. It will also void the warranty. Don't set this flag if you care about your warranty. I don't mind spending another $35 if I ruin this Raspberry Pi (although I will be sad if it breaks), but it's pretty unlikely that that will happen. It will probably die sooner than an unmodified device, but I'm OK with that.
For each test, I'll increase arm_freq by 100 MHz and see if the Raspberry Pi boots. If it does, I'll run the benchmarks. If not, I'll increment the over_voltage parameter by 1 until it does. If it still won't boot, I'll start backing off arm_freq in 25 MHz increments until I can get it to boot. I'll also increment the gpu_freq parameter by 25 MHz each time I increase arm_freq. It seems like gpu_freq (well, core_freq at least) can be increased to around 500 MHz without major problems, so it's unlikely that I'll hit the limit here with 25 MHz steps. Once the Raspberry Pi stops booting altogether then I'll know I've reached the upper limit of what this particular unit can do.
Reference Benchmarks
The video benchmark is fairly subjective, but watching it on the non-overclocked Raspberry Pi wasn't too pleasant. It froze briefly about every 15-20 seconds but it never crashed or anything. This is probably because the CPU can't decode the MKV container fast enough and not so much due to a lack of speed in the GPU, which uses its hardware H264 video decoder.
I calculated the GNUPG benchmark on three computers besides my Raspberry Pi: my desktop, which has a 3.1 GHz Intel Core i7-3770s CPU; my server, which has a 2.7 GHz AMD A4-3400; and my laptop, which has a 2.3 GHz Intel Core i3-2350M. The results are below:
| Processor | Score (s) (Smaller is better) |
|---|---|
| 3.1 GHz Intel Core i7-3770s | 7.88 |
| 2.7 GHz AMD A4-3400 | 14.22 |
| 2.3 GHz Intel Core i3-2350M | 13.90 |
| 800 MHz ARM1176JZF-S | 283.80 |
As expected, the Raspberry Pi's ARM processor is about 30 times slower than the other three machines. I don't expect it to come anywhere close to their performance, but this should give you an idea of how much slower the CPU on the Raspberry Pi is than that of a typical computer. I expect this benchmark to improve linearly with the clock speed, but we'll see what happens in the tests.
Results
| arm_freq (MHz) | gpu_freq (MHz) | over_voltage (Effective Voltage) | Benchmark (s) | Video Quality |
|---|---|---|---|---|
| 800 | 250 | 0 (1.2 V) | 283.80 | Video stutters about every 15 or 20 seconds; almost unwatchable |
| 900 | 275 | 0 (1.2 V) | 249.22 | Much better; stuttering only with lots of movement |
| 1000 | 300 | 2 (1.25 V) | 212.84 | Brief pause at the beginning of the file but otherwise perfect |
| 1100 | 325 | 6 (1.35 V) | 185.62 | Perfect. GUI also loads nearly instantly when the video ends |
After 1100 MHz I couldn't get the Raspberry Pi to reliably not eat the SD card, so that's where I stopped. Still, that's about a 35% improvement in performance and the video playback is much smoother now, so I'm happy. Here's a nice little chart showing the performance at various clock speeds.
I think I'll leave it clocked at 1100 MHz and see how stable it is over the course of the week. Hopefully I won't have to go much slower since anything below 1 GHz seems to not be quick enough for 1080p video.