RPi NAS: Extras – Overclocking

Raspberry Pi’s can be overclocked but could overclocking improve the performance of our NAS? In this post we’ll briefly discuss and test overclocking (and fix some problems it caused).

This post is part of a series about building a Network-Attached Storage (NAS) with redundancy using a Raspberry Pi (RPi). See here for a list of all posts in this series.

---

First things first: I’m only doing this test out of curiosity. The NAS is already fast enough for my purpose. Even if overclocking gives a speedup, I will stick with the default settings. That’s because I value stability, reliability and a long life of the Raspberry Pi more highly than any speed gains we might be able to get.

Also, if the network is not heavily used by other users then we can already write to the NAS at high speeds. So the potential for improvement is quite restricted¹.

Finally, you may be familiar with the concepts of a program being CPU bound, memory bound or some other kind bound (if not, it just means that the bottleneck that stops us from achieving higher speeds is the CPU, memory or something else). A priori I’d say that our bottleneck is not the CPU. Copying data is not a CPU intensive task. It does, however, require sufficient (PCI/USB) bandwidth to get the data to the disks and it does require fast write speeds of the disks. Increasing CPU frequency won’t help with those.

So why bother? Well, it’s always good to test your theories. There may be something influencing the outcome that you didn’t think of. Let’s get to it. For this test I use the official power supply and everything else is exactly as described in the main series about the RPi NAS.

Turbo Mode

First of all, there’s a turbo mode. On newer models of the Raspberry Pi 4B this mode increases the processor speed from 1.5GHz to 1.8GHz (see here for more information). It can be activated with the setting arm_boost=1 in /boot/config.txt. The setting was activated by default in the version of Raspberry Pi OS that I’ve been using (2023-10-10), so all numbers we saw earlier were obtained with a processor speed of 1.8GHz. As a side note, we can monitor the processor speed with
watch -n 1 vcgencmd measure_clock arm.

Since the speeds we obtain vary depending on the current setup (see post 5) let’s first do a speed test without any additional overclocking. I get the following numbers:

Overclocking in addition to default settings	Scenario 1 (MB/s)	Scenario 2 (MB/s)
None	115.98	95.78

First Overclocking Test

For the first overclocking test I tried the settings described here. According to that website these settings should still leave your warranty intact (I haven’t double-checked though). The settings, which are added to /boot/config.txt, are²:

over_voltage=6
arm_freq=2147
gpu_freq=750

With these settings the RPi locked up during the fifth copy in scenario 1. Up to that point I got an average speed of 116.17MB/s (over three observations, ignoring the first one). I then force-rebooted the RPi (with all drives attached) but it froze again before the GUI had finished loading. Disconnecting the drives, rebooting and only then reconnecting the drives worked. Then I ran scenario 2. This time the RPi didn’t freeze up completely but it still stopped copying during the fifth run. The average speed up to that point was 95.58MB/s (again over three observations, ignoring the first one).

Overclocking in addition to default settings	Scenario 1 (MB/s)	Scenario 2 (MB/s)
over_voltage=6, arm_freq=2147, gpu_freq=750	116.17	95.58

These speeds are similar to our first run without any overclocking. The lock ups are inconvenient though, to put it mildly. After another reboot Greyhole didn’t work because it encountered an error in the database it uses to keep track of tasks. It complained about some duplicate entry in the database:

PHP Fatal Error: Uncaught Exception: SQLSTATE[23038]: Integrity constraint violation: 1062 Duplicate entry ‘333875’ for key ‘PRIMARY’ in /usr/bin/greyhole:734 ….

Some Ad-Hoc Troubleshooting

The copy process must have frozen at a bad time. That’s slightly annoying but a good chance to illustrate some ad-hoc troubleshooting. I’m not really familiar with Greyhole’s internals but I know that it uses an SQL database (which is what the error referred to). Hopefully you will never see this error. In case you do, here’s how to deal with it:

• Open mariadb and log in as root with sudo mariadb -u root. If you have set a password then add -p to the command and enter your password.
• We can see all databases with SHOW DATABASES;. There should be one called greyhole.
• Select it with USE greyhole;.
• We can list all tables used by greyhole with SHOW TABLES;. There are a few of them but table tasks sounds promising.
• Let’s list some entries to see what it looks like with SELECT * FROM tasks LIMIT 10; (unfortunately I didn’t take a screenshot of the output while I worked on it). It looks like we’re in luck, one of the entries has the same ID as mentioned in the error message.
• I’m just going to brute-force delete all entries (they are all duplicates of the writes we do as part of the speed test) with DELETE FROM tasks;.
• We can check if the deletion worked with SELECT * FROM tasks;. The result should be an empty table.

Upon restarting the daemons of Samba and Greyhole (sudo systemctl restart smbd and sudo systemctl restart greyhole) everything worked again. Great.

Second Overclocking Test

Ok. Let’s reduce the overclock speed so hopefully there are no more lock-ups:

over_voltage=6
arm_freq=2147
gpu_freq=750

This time there are no lock-ups. In scenario 1 I got a speed of 116.45MB/s. In scenario two 96.47MB/s.

Overclocking in addition to default settings	Scenario 1 (MB/s)	Scenario 2 (MB/s)
over_voltage=6, arm_freq=2147, gpu_freq=750	116.45	96.47

Conclusion

There is virtually no difference between the results obtained by overclocking and those without. Of course, we could play around more with the exact settings but based on the considerations in the introduction I very much doubt that anything will change.

So there we have it. No surprises and no overclocking for my NAS.

---

Footnotes:

1. And if the network is used by other users and your router is too weak to satisfy all of them at full speed (like mine 5G router seems to be) then additional CPU speed won’t help either. ↩︎
2. After changing /boot/config.txt and rebooting you can run the command watch -n 1 vcgencmd measure_clock arm to make sure that the CPU runs at the requested frequency. ↩︎