Hacking Raspberry Pi (2014)
Part IV. Hacking the Raspberry Pi
Chapter 18. Raspberry Pi Overclocking
If you’ve made it this far into the book, then you’ve probably given your Raspberry Pi quite a workout. Accordingly, you are well aware of the hardware limitations of the diminutive Model A or Model B board.
How can you squeeze more performance out of your Pi? Can you do so safely? How does overclocking affect the limited warranty offered by Farnell and RS Components?
In this chapter I begin with a comprehensive tutorial on how to overclock your Raspberry Pi. Of course, you first need to understand exactly what overclocking means. Next, I give you everything you need to know to improve the performance of your Pi while staying within the bounds of warranty. Of course, if you want to go outside the bounds, then that’s okay, too. Just don’t knock on my door when something goes wrong!
I also address how to adjust the split between CPU and GPU memory allocation. For instance, if you work from the shell prompt, there is no reason to allocate any more RAM than is absolutely necessary to the GPU. On the other hand, if you have your Pi set up as a RaspBMC media center, then just the opposite may be true.
Let’s get to work!
What Is Overclocking?
Overclocking refers to forcing a computer component, such as the central processing unit (CPU), to operate faster than its default clock frequency.
The Pi’s ARM ARM1176JZF-S processor operates with the following default frequencies:
CPU: 700 million clock cycles/second (MHz)
GPU: 250MHz
SDRAM: 400Mhz
The Raspberry Pi is capable of processing one command per clock cycle, which means that the CPU processes 700 million instructions per second, the GPU processes 250 million, and the RAM chip 400 million. Those are a lot of instructions!
If you can force the Raspberry Pi to increase the clock rate for the CPU, GPU, or RAM, then it follows logically that the Pi will run faster by executing more commands per unit time. True enough.
The downside to the overclocking situation is heat. Hopefully it makes sense to you that an overclocked SoC requires more power and therefore generates more heat than an SoC running at its defaults.
You remember that the ordinary operating voltage of the Pi is 5V and that the typical current draw is between 700 and 1400 mA.
Note: Power to the Pi
All this talk of overclocking and performance improvements assumes that you provide the Pi with steady, reliable power. To do that you need to make sure you use a quality power supply before attempting to overclock your board.
Although overclocking in itself is reasonably safe, overvolting on the other hand will likely reduce the lifetime of your Pi by gradually degrading the SoC’s transistors and logic gates.
Some enthusiasts, myself included, aren’t overly worried about slightly reducing the lifetime of our Pis because the cost of replacement is eminently reasonable, but it’s a factor you should consider nonetheless.
Warranty Implications of Overclocking
The following is a relevant extract from Farnell’s Raspberry Pi Limited Warranty (http://is.gd/jF9ELL):
What does this limited warranty NOT cover?
Newark element14 has no obligation to repair, replace, or provide refunds in the following instances:
If the alleged defect arises because Customer has altered or repaired the Raspberry Pi without the prior written consent or authorization of Newark element 14
As I get to shortly, the Raspberry Pi Foundation does offer overclocking modes that do not void the warranty. Using these modes still qualifies you for a refund from the distributor.
The salient question on the mind of the enthusiast, is “How would Farnell or RS Components know if I tried to overclock or overvolt my Pi?”
As it happens, the Foundation programmed the SoC such that a so-called sticky bit is turned on when any of the following conditions is detected:
You set the temperature limit to a value above 85 degrees Celcius.
You force Turbo Mode or disable the current limit and set an overvoltage.
You can get a detailed description of exactly which overclocking options void the warranty on the eLinux.org website: http://is.gd/1HcNWb.
More about the sticky bit: As I said, this is a flip flop circuit that, once tripped, remains in place and is used by the distributors to detect whether you set your Pi to warranty-breaking settings.
You can tell if your Pi’s sticky bit is set by running the following command from a shell prompt and reviewing the Revision value:
cat /proc/cpuinfo
The word on the street is that any Revision value above 1000 means that your sticky bit is set and you do not qualify for a refund from the distributor.
Take a look at Figure 18.1. The first output shows my original Pi settings, which fall within the bounds of the warranty spec. The second output shows that the sticky bit has been tripped as a result of my setting an illegal overvoltage value.
FIGURE 18.1 This output shows my Raspberry Pi both pre and post-sticky bit.
I verified that resetting the run status of my Pi did nothing to change my CPU Revision value. To the best of my knowledge, after the sticky bit is flagged, your Pi is permanently out of warranty.
Overclocking Your Pi
Now that you understand what’s involved in overclocking, are you still willing to dig in, get your hands dirty, and boost the performance of your Pi? Great...so am I.
The Raspi-Config Method
The easy way to overclock your Raspberry Pi and to stay within warranty boundaries is to use the Raspi-Config script.
Start Raspi-Config by running the command sudo raspi-config and select the Overclock option from the main menu. Press Enter to go past the warning screen. You see that you can select one of five overclock presets; these are summarized for you in Table 18.1.
TABLE 18.1 Raspberry Pi Overclock Modes
The ARM/GPU core voltage values are a trifle mysterious. The default value of 0 denotes 1.2V, and a value of 6 represents 1.35V. The voltage increases in 0.024V steps between 0 and 6. You can overvolt up to a value of 8, which is 1.4V.
After you select an overclock preset, you’re prompted to reboot your Raspberry Pi for the change to go into effect.
The Raspberry Pi Foundation is rightly proud of the Turbo mode option; to that point, I’d like to explain how it works in more detail.
In addition to providing a big performance boost to your Pi, the Turbo mode dynamically adjusts your CPU, GPU, and SDRAM frequencies depending on the load your Pi experiences.
When the SoC temperature reaches its threshold value, Turbo mode automatically scales back the Pi speed to allow the system to cool down. Pretty cool, eh?
This Turbo mode magic is the result of a Linux kernel driver called cpufreq, which serves as a governor, or controller, over the Pi’s overclock status.
A Swedish programmer named Enrico Campidoglio wrote a cool Bash shell script that gives you your Pi’s CPU status details. The script also gives you “the deets” regarding voltage and temperature.
Task: Verifying Your Pi’s CPU, Voltage, and Temperature Status
This procedure should be accomplished from a terminal session (local or remote) on your Raspberry Pi.
1. Copy Enrico’s shell script contents (http://is.gd/h4q135) and paste the data into a new, blank file on your Pi. Save the file as cpustatus.sh.
2. Open a shell prompt and run the script from a Terminal session. You first have to mark the file as executable, however. For instance, the following shows you my command statement assuming that the script exists in my present working directory:
chmod +x cpustatus.sh
3. Cool! Now that the shell script can be run as executable code, let’s go ahead and run the script.
./cpustatus.sh
Remember that in Linux, you use the “dot slash” (./) notation to tell Raspbian that you want to run the given executable program from the present working directory. Otherwise, you would have to supply the full path to the file, such as /home/pi/cpustatus.sh. Sample output from the script file on my Raspberry Pi Model B is shown in Figure 18.2.
FIGURE 18.2 This Bash shell script provides you with useful, at-a-glance CPU metadata.
The Manual Method
The power user way to overclock or overvolt your Raspberry Pi is to manually edit the /boot/config.txt file. Recall that the Raspi-Config script, which is itself located in usr/bin, is nothing but a user-friendly front-end to the config.txt file.
From a shell prompt, let’s open the file for editing:
sudo nano /boot/config.txt
Scroll to the end of the file to see the parameters that are relevant to this discussion. Here are the default entries:
arm_freq: CPU clock frequency
core_freq: GPU clock frequency
sdram_freq: RAM clock frequency
over_voltage: Degree of overvoltage
The good news is that you can include additional parameters to take full control over our Pi’s overclocking experience. Here are three juicy options, as documented at the eLinux.org website (http://is.gd/1HcNWb):
temp_limit: You can modify the overheat protection by adjusting this threshold value. The default value is 85 degrees Celsius.
current_limit_override: Disables current limit protection. Remember that electrical current is directly proportional to voltage; enabling this option can help if your Raspberry Pi suffers reboot failures due to your configuring the overclock setting too high.
force_turbo: Disables the cpufreq driver and sets the Pi to run with highest settings all the time.
Note: Help! My Pi Won’t Boot
If during your overclocking and overvolting experiments you find that your Pi refuses to boot, then don’t fret. Instead, unplug the Pi, wait a couple of minutes, and then power on the device while holding down the Shift key. This disables any overclocking settings for the current boot only. You can then reset your Pi back to safer values, reboot again, and you should be good to go.
Benchmarking Your Pi
Okay...you are probably thinking, “Tim, I understand everything you’ve taught me so far, and I’ve overclocked my Pi. Although the device feels like it’s running faster, how can I prove this quantitatively?”
I’m glad you asked! Benchmarking refers to running tests that compare the current values of a process either to past values or to values generated by other, related processes.
Specifically with reference to the Pi, you can run benchmark tests against the device itself to gauge performance changes, such as before and after overclocking the processor cores and RAM.
There are a number of benchmarking utilities for Linux in general and the Raspberry Pi in particular. Here is a run-down of some of the most popular utilities and their associated websites in no particular order:
HardInfo: http://is.gd/sW7i7D
GtkPerf: http://is.gd/lsKamm
nbench: http://is.gd/Ql0MXe
Quake III Arena timedemo: http://is.gd/SBkoQq (building Quake III in Raspbian); http://is.gd/1p553T (timedemo instructions)
Because it is the benchmark used by Eben on the Raspberry Pi website, you learn here how to use nbench.
Interestingly, nbench (http://is.gd/mlJ2FO) is a command-line computer benchmarking utility that was developed originally by the long-deceased BYTE magazine in (wait for it) the mid-1990s. The tool measures a computer’s CPU, floating-point math co-processor, and memory subsystems by comparing your system’s results to two archaic reference machines:
Dell Pentium 90MHz with 256KB cache RAM and running MS-DOS
AMD/K6 233MHz with 512KB cache RAM and running Linux
The nbench software runs 10 tasks that each analyze a specific component of your target system’s performance; you can read more detail about the tests and algorithms by visiting http://is.gd/clvnY8. The system data nbench amasses is then compared to stored baseline data for the 90MHz and/or the 233MHz machines. The nbench in no way emulates the reference machines; all it has is stored benchmark data.
Task: Installing and Running nbench
Even after all these years, nbench can be a worthwhile performance benchmarking tool. Let’s run the tool against our Raspberry Pi.
1. Open a shell prompt and begin by downloading the nbench source code, unpacking it, and compiling it.
wget http://www.tux.org/~mayer/linux/nbench-byte-2.2.3.tar.gz
tar xzf nbench-byte-2.2.3.tar.gz
cd nbench-byte-2.2.3
make
The make step is doubtless unfamiliar to non-Linux computer users. To be sure, it’s a different paradigm to think of obtaining a program’s source code and compiling it into executable form manually. Thus, the make program assembles all the parts and pieces that comprise a piece of software and compiles the code into executable form.
2. Make sure you have everything but your Terminal session closed or stopped. Next, start the nbench tool.
./nbench
In Figure 18.3 you can see my benchmark results using my Model B board that runs in Turbo mode.
FIGURE 18.3 The BYTEmark (nbench) benchmark is particularly popular among Raspberry Pi enthusiasts.
It’s one thing to run a benchmark program and quite another to understand what it means. You can see that nbench puts your Raspberry Pi through 10 different tasks. What’s important, speaking analytically, isn’t comparing your system’s results to the reference systems. Instead, you should compare the figures against your own Pi say, before and after enabling overclock settings. You can also compare your nbench results with other Raspberry Pi users, for instance, on the Raspberry Pi Forums (http://is.gd/6nBR5Z).
Adjusting the Memory Split on Your Pi
In addition to overclocking, you also have the ability to modify the CPU/GPU memory split to accentuate system performance on your Raspberry Pi.
You already know that the Broadcom BCM 2835 SoC has two processors (CPU and GPU), as well as the SDRAM. You also know that the Model B board includes 512MB of RAM, while the Model B board includes 256MB.
You can adjust the balance between how much RAM is allocated to the CPU vs. the GPU. This can be helpful if, for instance, you perform mostly graphics-intensive tasks such as playing games or transcoding video.
On the other hand, if your Pi is set up to run only or mostly with the Terminal, then it does not make sense to allocate any more RAM than necessary to the VideoCore IV GPU.
As you read with the overclocking discussion, you can tweak the memory split either with Raspi-Config or manually.
Task: Tweaking Memory Split with Raspi-Config
In this procedure you take control over the CPU/GPU memory split on your Raspberry Pi. Perform these steps on your Pi.
1. Open Raspi-Config and navigate to Advanced Options. Next, select Memory Split.
2. You are asked the question How much memory should the GPU have? Supply a legal value and press Tab to select OK. The legal values for the Model B are the following, which represent megabytes (MB) of RAM:
16
32
64
128
256
Note: Regarding the RAM Split on the Raspberry Pi Model A
The RAM allocation values presented here are obviously for the Model B board. The Model A board supports all values less than or equal to 128.
3. You are prompted to reboot, after which your Pi reserves the designated amount of RAM to the GPU. Any RAM left over is left by default to the CPU.
As far as suggested splits are concerned, I share with you here what I use on my Model B boards. For servers that aren’t doing much of anything, I use a 240/16 CPU/GPU split. For my gaming rigs and media center devices, I use a 256/256 split with no issues.
Tweaking Memory Split by Hand
We learned in Chapter 17, “Raspberry Pi Security and Privacy Device,” what /boot/config.txt is and how to edit this crucial system configuration file. Thus, we get directly to the relevant parameters:
gpu_mem: RAM devoted to the GPU. The CPU gets any remaining memory.
cma_lwm: When the GPU has less than this low water mark amount of RAM, it requests more from the ARM CPU.
cma_hwm: When the GPU has more than this high water mark amount of RAM, it releases some to the CPU.
To set the cma_lwn or cma_hwm dynamic memory split parameters, you need to add the following line to your /boot/cmdline.txt file:
coherent_pool=6M smsc95xx. turbo_mode=N
Note: For the Especially Brave...
Before experimenting with the dynamic memory split parameters, I advise you to update your Linux kernel to the latest available. I gave instructions for doing so back in Chapter 4, “Installing and Configuring an Operating System.”
The cmdline.txt configuration file contains low-level commands that are sent directly to the Raspbian Linux firmware at boot time. The file consists of key/value pairs separated by a space. Therefore, you should just add the line of code just given as a new entry to the file, save changes, and reboot.
To see your Pi’s current cmdline data, run the following command from a shell prompt:
cat /proc/cmdline
A Historical Footnote
In earlier Raspbian releases, the /boot partition contained multiple GPU firmware files:
start.elf
arm128_start.elf
arm192_start.elf
arm224_start.elf
arm240_start.elf
The original idea was that you could change the CPU/GPU memory split by overwriting the “live” start.elf file with one of the arm* files. Thus, by running the following example statement:
cp /boot/arm240_start.elf /boot/start.elf
you configure your Pi with a 240MB ARM/15MB GPU split. Nowadays the /boot partition contains just a single start.elf GPU firmware image. You can see the Raspberry Pi kernel, firmware, and configuration files in Figure 18.4.
FIGURE 18.4 The Raspberry Pi kernel, firmware, and boot files are located on the FAT32 /boot partition (the only part of the SD card that is readable by Windows).
Just for the sake of completeness, I want to provide you with a brief description of the /boot partition contents; check out Table 18.2 for that useful nugget of information.
TABLE 18.2 Raspberry Pi /boot Partition Contents
Remember our friend Hexxeh (http://is.gd/Rrh2bS)? This is the individual who gave us a splendid, easy-to-implement method for updating Raspberry Pi’s firmware:
sudo apt-get install rpi-update
sudo apt-get install git-core
sudo wget https://raw.github.com/Hexxeh/rpi-update/master/rpi-update -O /usr/bin/
rpi-update && sudo chmod +x /usr/bin/rpi-update
sudo rpi-update
Note: What Is Git?
You probably noticed that many of the installation recipes in this book use a software product called Git. Git (http://is.gd/5vKXkJ) is a free, open source, distributed software version control system. Git enables developers to publish their projects and source code so that people can access their stuff in myriad ways. If you have any interest in writing your own open source software, you want to spend time getting to know Git.
The reason I mention Hexxeh’s tool is that it once allowed you to change the ARM/GPU memory split. Now, however, Hexxeh recommends using the Raspi-config or manual methods as previously outlined.
Various and Sundry Performance Tweaks
The IT security and performance principle of least service means that if your computer does not need to have a particular background service (daemon) running, then prevent it from doing so. Not only will your computer run faster, but you also reduce the attack surface of the machine. After all, an attacker can’t compromise a service that isn’t running!
To that end, you can use the sysv-rc-conf utility (http://is.gd/1VjHLP) to analyze your startup services and disable any that you identify as unnecessary.
sudo apt-get install -y sysv-rc-conf
sudo sysv-rc-conf
As you can see in Figure 18.5, the sysv-rc-conf presents a table showing you everything that’s running in the background on your Pi. You can use the keyboard arrow keys to move around the table and press the Spacebar to toggle services on and off for the various run levels (that’s what the 1–6 and S mean in the column headings). Press Q to quit the tool and to return to your shell prompt.
FIGURE 18.5 You can use the sysv-rc-conf utility to disable startup services that you don’t need and thereby boost the performance and security of your Raspberry Pi.
Naturally, you’ll want to do some research on what these services actually do before you disable anything.
Note: About Run Levels
The Linux operating system can run under different levels of processing priority and system access; these are reasonably called runlevels. Only one runlevel is executed on each startup. For instance, runlevel 0 is used to shut down the system. Runlevel 1 is single-user mode, in which only one login is allowed. Runlevels 2–5 are for multi-user access. Runlevel 6 denotes a reboot condition. You can read more about runlevels on Wikipedia at http://is.gd/rTxUO6.
By default, the Raspberry Pi reserves six connection terminals (called tty connections) for simultaneous user access. If you are the only person logging into your Pi, then you can save some system resources by reducing this number.
Open the /etc/inittab file in nano or your favorite text editor:
sudo nano /etc/inittab
Now, comment out the unneeded terminal reservations. On my system, I want to reserve only two connections:
1:2345:respawn:/sbin/getty --noclear 38400 tty1
2:23:respawn:/sbin/getty 38400 tty2
# 3:23:respawn:/sbin/getty 38400 tty3
# 4:23:respawn:/sbin/getty 38400 tty4
# 5:23:respawn:/sbin/getty 38400 tty5
# 6:23:respawn:/sbin/getty 38400 tty6
Save your changes, close the /etc/inittab file, and reboot your Pi to put the change into effect.
Finally, you can make use of a couple cool apt-get parameters to keep your installed software and repository cache nice and tidy:
sudo apt-get autoremove
sudo apt-get autoclean
The autoremove parameter removes software packages that were installed by apt-get automatically to satisfy dependencies for some installed and potentially removed software.
The autoclean parameter clears out your local repository of retrieved package files, removing only package files that are no longer valid.
For best performance, I suggest you run those apt-get statements on your Pi every month or so.