Pragmatic Overclocking

Overclocking the Raspberry Pi 3 – Free Speed and Trade-offs

The Raspberry Pi 3, in common with the the older Pi 1 and Pi 2 models, can be overclocked – that is, the main processor, graphics chip, and memory, can be run faster than the default factory settings. Whilst more speed equals more processing power, there’s a trade-off to be considered with the new hardware that generally wasn’t an issue on the earlier systems.

Please Note: at time of writing overclocking the Pi 3 does not appear to be officially sanctioned. This is noted in a post on Gordons Projects, and can be seen in the overclocking entry in the Raspbian O/S’s raspi-config tool, which states ‘This Pi cannot be overclocked’. I do not know whether implementing any overclock options on the Pi 3 will set any internal flags and affect your warranty (early generation Pi’s do so if the Governor is bypassed). If in doubt, wait until the Raspberry Pi foundation makes a statement on the subject.

Nevertheless, the new Pi can certainly be overclocked. Whilst the process by which this is achieved remains the fundamentally the same, editing the config.txt file, overclocking is not quite as straightforward as it previously has been. The issue is one of thermodynamics, as the new model runs somewhat hotter than the those of the previous generations, at least in the case of the Pi which I took delivery of the day after the new model was released*

* The presence of high CPU temperatures on the new machine could be limited to a certain batch, or an example of the variations in CPU tolerances such as those resulting from lithographic techniques used to create the processors.

Blogger JackenHack wrote of his own overclocking experiments very soon after the Pi 3 was released, and noted that of his two specimins, one ran cool and was very overclockable, whilst the other ran hot and was not. Another post I’ve read stated that the owner’s Pi 3’s thermal governor (see later) did not appear to be active, leading to an inherently unstable, overheating machine.

In the past overclocking was basically a question of pushing the Pi’s hardware as fast as it would run, whilst maintaining stability; this latter point is important, as simply completing the boot process, or successfully loading Raspbian, RetroPie, or Kodi, for example, is not indicative of a reliable system. I covered the importance of testing when overclocking, and various tools to help do so, in a series of earlier posts:

• Part 1: Overclocking the Raspberry Pi
• Part 2: Stress testing the CPU with mprime
• Part 3: Stress testing the RAM with Memtester
• Part 4: Stress testing the SD card storage with the Stability Test Script

As soon as I began overclocking my Raspberry Pi 3 I found that heat was an issue, where it had never been a problem on the Pi 1 or 2. Running stress tests on the system, pushing all four CPU cores to their limits, even before overclocking, the processor was approaching the limit at which the Pi’s thermal governor is activated.

A working definition of the governor can be found on Enrico Campidoglio‘s blog post from 2013; whilst this references the original model Pi, the information remains relevant through all incarnations:

[The governor] is a piece of the Linux kernel driver called cpufreq that’s responsible for adjusting the speed of the processor. The governor is the strategy that regulates exactly when and how much the CPU frequency will be scaled up and down. The one that’s currently in use is called ondemand and it’s the foundation upon which the entire Turbo Mode is built.

Once the Governor activates the overclocking values are bypassed as the system attempts to prevent the temperature breaching a given threshold, which by default is 80 degrees centigrade. Not only are the overclock values overridden, but the clock speeds can actually fall below the defaults (‘underclock’) if this is required to reduce the component temperatures.

It’s worth noting that the Pi will also underclock when running under light loads, reducing power consumption and temperatures. The default clock values for the three main components, and their default underclock values are as follows:

Raspberry Pi 3 Default Clock, and Underclock, Values

Pi 3 Default Clock Settings
arm_freq=1200
core_freq=400
sdram_freq=450


Pi 3 Default Underclock Settings
arm_freq=600
core_freq=250
sdram_freq=450


(all values are in MHz)

Note: I believe that the Sdram is not dynamically clocked, but cannot be certain. I’ve not yet discovered a vcgencmd measure_clock setting (or equivalent) to measure this at runtime, although the voltages applied can be read.

With no overclock values applied, running the stress test MPrime on all four CPU cores raised the system temperature to a peak of 79.9 degrees centigrade during a 10 minute run. As soon as the CPU was overclocked, the same test swiftly caused the thermal limit to be reached, activating the Governor, and deactivating the overclocking. As more aggressive overclocking was applied, the temperatures generated resulted in the system underclocking the CPU, to as low as 900mhz.

Notably, running 4 simultaneous instances of Memtester (1 per CPU core) resulted in the governor taking effect even on with standard, non-overclocked settings; this test generates large amounts of heat as both the CPU and RAM are extensively exercised; both chips a situated next to each-other on the Pi 3’s motherboard – the CPU as part as the SoC Broadcom chip on the top of the board, the RAM directly below on the underside.

Over-Temperature Warning Icon

I initially set up the Pi 3 using the Noobs Raspbian image, with a view to running both Raspbian and the OSMC media center from the same SD card, on separate partitions. I subsequently found a better solution, and reinstalled my Pi 3 using a larger SD card. Although this was only two weeks after the initial installation, the reinstalled system surprised me by indicating the over-temperature condition with a small square orange/yellow icon in the top-right corner of the display.

The transparency and vibrancy of the icon appears to correlate with the temperature and/or how aggressively the governor is underclocking the CPU and GPU in order to keep below the thermal limit. The over-temperature icon can be seen in the following image, in which four instances of Memtester are running, the temperature has exceeded 80 degrees Celsius; as a result the ARM has been dynamically underclocked to 1053 mhz (dropping as low as 850mhz):

Please note: normally I run overclocking tests from the Bash shell (a.k.a command line), using the Screen tool to create run multiple instances as necessary. For purposes of illustration, here I am simply running multiple Bash shells from the Raspbian desktop.

At present I cannot account for the lack of the over-temperature icon on the earlier build; the versions of Raspbian are virtually identical (Noobs: 4.1.18-v7+1 #846 vs Standalone Raspbian: 4.1.19-v7+1 #853), the hardware is identical (baring the SD card),the firmware version is the same, and the icon itself has been present in that firmware since at least February 2015. There were no entries present in the config.txt settings file to account for the icon being suppressed.

To prevent the over-temperature (Yellow) and under-voltage (rainbow, a miniature version of the power-on splash-screen) icons from being displayed (whilst leaving the governor enabled, protecting the system), add the following to the /boot/config.txt file:

avoid_warnings=1

After a great many tests, in a large number of combinations, my machine appears to be stable with the following settings:

Raspberry Pi 3 Stable Overclock Values
arm_freq=1350
core_freq=500
over_voltage=4


All attempts to overclock the RAM were unsuccessful. Notably this is the same RAM as present on the Pi 2, upon which I had the same negative results when attempting to overclock.

Whilst the GPU (core_freq) has been increased from 400mhz to 500mhz, I’ve not yet found a substantial test to check the stability of this component. An OpenGL test suite which I installed appeared to tax the GPU, but the system reported that it was underclocking this chip to 250mhz during the tests. In contrast, when running various emulators the GPU is clocked at 500mhz.

Pragmatic Overclocking

Tuning overclocking on the Pi 3, for me, is a case of determining the use to which the machine is primarily put to, and optimising accordingly.

Evidently there would be little point in applying overclocking only for the system to generate so much heat that the governor underclocks the CPU and GPU to values lower than the defaults. Whilst running stress-tests is necessary to ensure that the Pi will be reliable under worst-case conditions, it is generally unlikely that in real-world usage the system will have all four processor cores fully loaded, with each core heavily accessing the Ram, and the GPU running at full-tilt.

One of the main use-cases for my Pi 3 is running RetroPie, which includes a suite of video console and computer emulators. Those which I tend to use in all utilise a single CPU core (this is true of Sega megadrive, 32X, Snes, Atari 2600, PlayStation, N64, Mame, and entries in the Ports section, including Quake and Quake 3: Arena).

Running one, two, or even three cores at maximum tends to generate temperatures below the thermal threshold; certainly in all tests I have conducted on the aforementioned RetroPie emulators, the temperature never climbs above 60 degrees Celcius. For this use case, it makes sense to overclock the processor as fast as it will run whilst maintaining stability – whilst multi-core tests will cause the governor to underclock the CPU, this will not occur in real-world use, allowing the emulators to benefit from the fully-overclocked speed boost.

Whilst the emulators included in RetroPie are generally single-core, various programmes installed for use under the Raspbian O/S are multi-core capable. A couple which I use are GIMP (‘GNU Image Manipulation Program’), which has a ‘Number of Processors to Use’ Preference, and VLC. Whilst I have not witnessed GIMP overtaxing the CPU, VLC will do so if used for video playback, as on the Pi this is not hardware accelerated, and results in all 4 cores running at 100%, whilst failing to playback video smoothly, if at all. For audio playback, however VLC is perfect, and generally uses at most 1 percent of the total CPU.

Test Each Component In Isolation, and Test Thoroughly

A note on testing to ensure stability:

For several days I had the sdram_freq set to 500, which appeared to be working without issue. Later it transpired that I’d been running only the CPU test MPrime, rather the Memtester ram tests. This was, I’ll admit, partly due to laziness, as setting up screen to run four console sessions, with each running a Memtester instance becomes labourious. Under real-world usage (Raspbian, Kodi Media Center, and various emulators in the RetroPie suite) all was well; when running Memtester on all cores, however, the system always failed, even with the RAM modestly overclocked to 475Mhz. When overclocking, through, methodical testing is the key.

Regarding Memtester, it’s also worth noting that on a couple of occasions I witnessed odd behaviour which I initially attributed to failures due to overclocking instability. Further investigation has lead me to conclude that Raspbian can become unstable in strange ways if too much memory is consumed by parallel instances on Memtester running.

Normally the Memtester tool will attempt to mlock the memory under test, effectively ring-fencing it; also, the OOM (Out-of-memory) Process Killer generally shuts down instances of Memtester if the Kernel cannot acquire enough RAM to undertake necessary operations. During tests the system once become unresponsive, appearing to have frozen, but to be accessible (given enough patience) from an SSH session, or from the local console. Attempts to shutdown Memtester via Control+Z were ignored; screen and Memtester had to be stopped via kill. In one instance the signal to the attached DVI monitor was inexplicably shutdown.

For details of multiple combinations of overclock settings on my Raspberry Pi 3, both successes and failures, please see the following page

A Labour of Love

Retro Resolution is entirely a labour of love. Please consider offering a donation if the information here has helped illuminate, enlighten, or otherwise assisted you!

Related Posts

• Links: Raspberry Pi and Gaming Emulation via RetroPie
• Don’t Fear The Command Line: Raspbian Linux Shell Commands and Tools – Part 1: Just the Basics
• Navigating the Raspberry Pi’s File System. Raspbian Linux Shell Commands and Tools – Part 2

Overclocking and Stability Testing the Raspberry Pi

• Part 1: Overclocking
• Part 2: Stress testing the CPU with mprime
• Part 3: Stress testing the RAM with Memtester
• Part 4: Stress testing the SD card storage with the Stability Test Script

About
Disclaimers
Privacy Policy
Terms and Conditions
© Retro Resolution