Overclocking Raspberry PI 3, part 2

If you havent read my first installment then head back and read it here.

Right. Overclocking is not something that should be taken lightly. I have seen people get cpu-burn and basically kill their brand new Intel i7 CPU’s – effectively throwing well over a thousand dollars worth of gear straight out the window.

My idea of overclocking is not to push the cpu to the bleeding edge. Moderation is the keyword here. Its like when we were kids and bought trim-set’s for our mopeds and dirt-bikes. Filing down the intake on the cylinder and pumping more gasoline in could get that 50cc engine yielding 70 KPM rather than the default 50. But if you filed even 5mm too much, you could pretty much throw the whole cylinder in the thrash. And if you didn’t get a dedicated cylinder with better cooling — the whole engine would burn out.

The test

You can get some heavy-duty performance test-kits for Linux, but for moderate overclocking I find that practical, hands on testing works just as well. In my case I have used a simple JavaScript demo (actually a port of a JS68k demo to Smart Pascal) that I compiled on my PC and dumped on my server.

On my Raspberry PI I just start Chromium and let the demo run.

Without overclocking I get the following performance factors:

• 1-2 frames per second
• 46-57% CPU usage in task-manager

Preparing the hardware

I bought a simple, cheap set of 3 heat-sinks for around $2. So first order of the day is to get that attached to the 3 chips that more or less make up the Raspberry PI 3b.

Heatsinks + fans all humming nicely!

My son managed to play a cheap graphics card to death earlier, which just happened to have a small fan. So I took that fan and attached it to the heat-sink with a double-sided tape pad, then connected the power cords to the GPIO pins. This ensures a reasonable degree of cooling. Not top of the line liquid stuff – but a lot better than just heatsinks alone. And hey, it’s a $35 SoC, so heat sink pluss fan is pretty much giving it the royal treatment.

That’s one pimped up Amiga 500! 🙂

The settings

Next is to adjust the config file to perform the actual overclocking. Again, I stick to safe values. You could probably push this further by adjusting sdram read and write frequencies — but you may end up burning the whole thing to pieces. Also, the keyword here is “safe”. To much overclocking and the amount of computational errors actually renders the whole thing useless.

Not running out of SD card slots any time soon!

Start a command-line prompt and do:

cd ..
cd ..
cd boot
sudo nano config.txt

Now scroll down until you find

#uncomment to overclock the arm. 700 MHz is the default.

Replace the values there with:

#uncomment to overclock the arm. 700 MHz is the default.
arm_freq=1350
over_voltage=5
sdram_freq=500
gpu_freq=500
core_freq=575

Next, hit CTRL+X, press Y, then enter to save the file. Now type:

reboot

Performance test

Now simply start Chromium again and run the demo. The performance have now gone up quite considerably:

• 8-9 frames per second
• 42% CPU usage in task-manager

From 1-2 FPS to 8-9 is actually a MASSIVE speedup

Now let’s check the temp. From what I read, the core will blow at around 80 degrees, so no matter what you decide to do – make sure it stays well below that.

Open up a command-line prompt and type the following:

/opt/vc/bin/vcgencmd measure_temp

Keep an eye out on the temp, let it run for a while and make sure all is safe

Let’s do some maths

Since the JavaScript demo is a “per-pixel demo”, meaning that it uses the canvas to draw stuff, with a secondary callback cycle applying an alpha clear to give the impression of fading pixels out ( fillrect(0,0,width,height, rgba(0,0,0,0.3)) ) running out of sync — the demo is actually processing millions of bytes per frame.

Just for sake of argument, lets say the chrome window is “1024 x 1024” in 32 bit mode (which is an understatement, but let’s go with that). We then get:

• 1024 * 4 (four bytes per 32 bit pixel) = 4096 bytes per scanline
• 4096 * 1024 = 4,194304 million bytes per frame

There is also a stride offset, but I will ignore that since it probably amounts to about 1kb or less. Right, since we are now drawing 9 frames instead of 2, this gives us:

7 * 4194304 = 29360128 – a boost of 29.3 million bytes per second

Final words

Im sure you can overclock the shit out of this if you really want, but honestly — I would rather have a piece of kit I can trust, that is stable, that dont renders the device useless in six months time – and that gives me that little extra I need for my embedded work (or Amiga emulation for that matter).

Well, that’s it for now — Remember to practise safe hex!