Home > JavaScript, Object Pascal, OP4JS, Raspberry PI, Smart Mobile Studio > Overclocking the Raspberry PI 3

Overclocking the Raspberry PI 3

November 17, 2016 Leave a comment Go to comments

On the menu for today was a meeting with my partner in crime, Glenn, who is working hard on the Raspberry PI Linux distro for Smart Mobile Studio – and then do some Linux stuff. For the Smart Pascal headers to actually fit the latest stuff I needed (doh) the latest version of Node to test on. Which has to be built from C/C++ source code on the Arm device.

Building purely from C/C++ source on a PI is .. probably the worst thing I did all day. Cross-compile from your PC instead

Building purely from C/C++ source on a PI is .. probably the worst thing I did all day. Cross-compile from your PC instead

So I baked a fresh copy of Raspbian with the sexy new Pixel UI, updated packages and so on. I set the CPU in performance mode (yes the CPU has different modes) before doing a compile — installed git, cloned out the latest nodejs repository and hit configure + make.

Well, its been 60+ minutes since the bloody build started so I thought, hey why not overclock the sucker and at least shave some off the waiting. But sadly overclocking is not supported by the official Raspbian system settings.

After a bit of google time I found a guy that had gone through the ropes and settled on a sexy 1400 frequency overclock with an over-voltage at around 6. This is stable and the core temp when spawning 4 intense 100% threads (one for each core) is around 58-60 degrees. In other words, well within the specifications (the cpu blows at around 80 degrees and will also kick the bucket at -40).


The dark side of the force is a pathway to many abilities, some considered unnatural

So — you do this at your own risk. Do not attempt this unless you understand the risk. By overclocking you can kiss the warranty good-bye, and I take NO RESPONSEBILITY for whatever damage or loss this could cause. You are on your own when you overclock anything, be it your dishwasher, PC or Raspberry PI embedded boards.

Having said that, the worst that can happen is that you kill your PI. Not exactly a heart breaking loss since they retail at around $35. In most cases when a CPU gets to warm it just shuts down or programs crash. So should that happen let it cool, then use a normal image and leave overclocking alone.

Heat sinks

Yes it may look silly, but if you overclock anything you need to delegate the extra heat somewhere. You can get a heat-sink set for around $1-$3 depending on the vendor. I ordered a couple of sets from Asia at around $2. You get the same kit at RC components for roughly the same price.

Tiny little things with double-sided sticky tape. Works like a charm.

Tiny little things with double-sided sticky tape. Works like a charm.

Ironically it’s not just the CPU that overheat, but also the USB controller and WIFI chip. Thats why a trim-set typically ships with 3 mini heat sinks.

Let there be light!

Boot your PI with a normal raspberry image (and take a backup in case of karma). When you get to the desktop, open a command-prompt and cd all the way back to root (/). Then cd into the boot folder. Inside the boot folder you will find a file called “config.txt”. You need to edit this file with admin rights:

sudo nano config.txt

This opens up nano, a dos like text editor. Just scroll down until you find:

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

Change that to the following:

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

hit CTRL+x, when asked if you want to save – hit “y”. The file is now saved and the next time you boot – it should run at 1.45 GHz. Which is quite nice

To reboot, just type


This is the setting that works best for me:

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

The sdram overclocking might not work at all (did for me though), and some PI’s actually wont run any faster above arm_freq=1300, but mine works fine with the above settings.

From 3 FPS to 7 FPS! We are talking millions of pixels per frame, and going from 3 to 7 FPS is quite a boost!

Click for video!!! From 3 FPS to 7 FPS! We are talking millions of pixels per frame, and going from 3 to 7 FPS is quite a boost!

Also note that if it wont boot, just plug the sd-card into your PC and edit the config.txt there in notepad (the boot folder on the pi is actually a mapping to the windows fat32 partition).

Remember to fit the heat-sinks BEFORE you boot (!)


Since some guy has posted “you dont understand the raspberry PI” in the comment section I just want to respond to that briefly.

Yes, you are partly right, there are aspects of the PI I dont have a clue about. Nor do I pretend to be guru about every piece of tech i come into contact with (that would be a very booring life IMHO). In fact, what I think is exciting about that little machine is that you can tinker and learn as you go – and that even mid-level users like myself can get results.

The JavaScript demo I used to test the clocking is actually a reasonable starting point. At first it was running at roughly 1 fps (due to poor coding, I used timers rather than RequestAnimationFrame to synchronize redraw). By just changing the arm_freq to 1350 this doubled, to a whopping 2 fps.

After i tweaked the memory clock-speed and gpu and set some overvoltage, that in turn went up to a stable 7 fps.

Since this 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 probably a bit small, but lets 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 7 frames instead of 3, this gives us:

4 * 4194304 = 16,777216 – a boost of 16.7 million bytes per second


I may not be a Raspberry PI guru, nor would I pretend to be one, but boosting the javascript virtual machine by that magnitude is pretty good. And remember: JavaScript is single threaded. I have yet to see what happens when we use all the cores here.

But I am open for information and would love to hear your take on this. Im sure we can dig down and find out exactly which of my settings had the most impact.

Either way: overclocking and tuning the Raspberry PI 3 for better performance is possible. And that was the only thing on the table here.

  1. November 17, 2016 at 9:57 am

    You dont understand raspberry, Raspberry 1 have a 700 mhz default, Raspberry 3 have a 1300 Mhz default

    • November 17, 2016 at 12:33 pm

      Wow, really? I know it runs on 1300. The numbers you are refering to is from the config.txt file that ships with raspbian. They should change that.

      The setting i am running at which is stable is simply:


      Which represents a humble, but very noticable improvement. The odd bit is that some PI’s you can amp up to 1450 without problems, but others never go passed 1300/1350.
      So not all PI’s are the same.

      A Javascript particle demo that i executed before tweaking, which processes millions of pixels per frame — ran at a flat rate of 3 FPS.
      After tweaking the clocks it now runs at 7 (with a larger window). That is a significant speed increse. So i beg to differ on your statement.

  1. No trackbacks yet.

Leave a Reply

Please log in using one of these methods to post your comment:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: