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.
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.
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.
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:
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:
Let’s do some maths
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
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!