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.
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
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
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!
with raspberry pi 2, I get 9 to 10 FPS and 37C with 1000mhz clock. some ting is wrong in your bord or driver, I use chromium under rasbian
details
Linux raspberrypi 4.4.48-v7+ #964 SMP Mon Feb 13 16:57:51 GMT 2017 armv7l GNU/Linux
Architecture: armv7l
Byte Order: Little Endian
CPU(s): 4
On-line CPU(s) list: 0-3
Thread(s) per core: 1
Core(s) per socket: 4
Socket(s): 1
Model name: ARMv7 Processor rev 5 (v7l)
CPU max MHz: 1000,0000
CPU min MHz: 600,0000
BR
try this: quartexhq.myasustor.com/particles/