Overclocking

[PiGraham]

Some more Googling turned up this possible answer, which I assume will also apply to Zero W:

To prevent misunderstandings:
Not a bug in the Zero, but in the overclocking sw. Fixed in next release, not next batch of the Zero.

Just to clarify this is purely an issue with raspi-config (and the GUI Pi config utility which uses raspi-config).
You are free to manually edit config.txt. "arm_freq=1100" will work just as it always has in the past.

[pi3g]

Is there a definitive list of the most stable over/under clocking settings for the different pi models a bit like this?

I've built a web-based tool, which will allow you to select presets for Pi 4 / Pi 400 / Pi 3B:

Overclocking tool for Pi 4 / Pi 400 / Pi 3B

raspberry-pi-overclocking-webtool.jpg (31.33 KiB) Viewed 4357 times

overclock-maximum-performance-pi400.jpg (38.36 KiB) Viewed 4357 times

There are two presets, medium booster and maximum performance. The tool will also warn you if you're about to set the warranty bit.

You'll be able to download the presets as a file, and my page also explains how to add it to config.txt

Feedback on which settings to put into the tool for other Pis is very welcome

Max

[DougieLawson]

What about the 2B V1.2 (with the BCM2837) and the 3B+?

The "warranty bit" has been eliminated from some of the later models.
viewtopic.php?t=283911#p1718810

[pi3g]

What about the 2B V1.2 (with the BCM2837) and the 3B+?

The "warranty bit" has been eliminated from some of the later models.
viewtopic.php?t=283911#p1718810

Thanks for your feedback!

Yes, I've read about the warranty bit not being of particular importance - still thought it's better to be 100 % safe than sorry ...

In my research it seems that the 3B+ is not particularly well suited for being overclocked, as it already has been clocked at it's limits.
Do you have a different overclocking experience with the 3B+?

Concerning the 2B: I wanted to do the most popular models first, and add additional overclocking further down the line - it seems most people are interested in the Pi 4 (and 400 by extension, I think).

I'll make a note of the 2B v1.2, and try to add it in the coming days.

Cheers,
Max

[jahboater]

In my research it seems that the 3B+ is not particularly well suited for being overclocked, as it already has been clocked at it's limits.
Do you have a different overclocking experience with the 3B+?

I agree. I only ever managed a truly stable overclock of 25MHz The 40nm node size was at its limit.

The Pi4 has an enormous margin by comparison, 600MHz or more.

[pi3g]

Do you have any experience with the Pi 2 v1.2?

[jahboater]

Do you have any experience with the Pi 2 v1.2?

No, sorry.

My guess is that it might approach Pi3 speeds.

[pi3g]

Yes, right - since they're based on the same SoC that seems reasonable

[jahboater]

Yes, right - since they're based on the same SoC that seems reasonable

It hasn't got the fancy thermal management that the Pi3B+ (plus) has.

[pi3g]

Ah, I was thinking of the Pi 3B - that would be more comparable. Sorry for not being clear (Pi 3, for me, is Pi 3B, and Pi 3B+ is Pi 3B+)

[pi3g]

I've now added more models, including Raspberry Pi 2 v1.2 as suggested to my Raspberry Pi overclocking tool.

overclock-raspberry-pi-new-options.jpg (37.54 KiB) Viewed 4195 times

[aBUGSworstnightmare]

I've now added more models, including Raspberry Pi 2 v1.2 as suggested to my Raspberry Pi overclocking tool.

overclock-raspberry-pi-new-options.jpg

medium booster settings for Pi400 proposed by this tool don't work for me on my Pi400, neither running FKMS nor KMS on latest 5.10 kernel. Need to add that I have a DPI display connected to GPIO.

[ejolson]

I've now added more models, including Raspberry Pi 2 v1.2 as suggested to my Raspberry Pi overclocking tool.

overclock-raspberry-pi-new-options.jpg

To be useful it would be nice if the over clocking tool had built-in diagnostics to check the system was somewhat stable after performing the adjustments.

[pi3g]

I've now added more models, including Raspberry Pi 2 v1.2 as suggested to my Raspberry Pi overclocking tool.

overclock-raspberry-pi-new-options.jpg

medium booster settings for Pi400 proposed by this tool don't work for me on my Pi400, neither running FKMS nor KMS on latest 5.10 kernel. Need to add that I have a DPI display connected to GPIO.

Would you be able to test without the DPI display? (Unlikely that it has an effect, but maybe ...)
I'll also look into it again tomorrow morning, these medium settings are meant to be broadly compatible with most Pis, therefore your feedback is really valuable to me.

Thanks
Max

[pi3g]

I've now added more models, including Raspberry Pi 2 v1.2 as suggested to my Raspberry Pi overclocking tool.

overclock-raspberry-pi-new-options.jpg

To be useful it would be nice if the over clocking tool had built-in diagnostics to check the system was somewhat stable after performing the adjustments.

Thanks for the feedback - I'll add it to my list of planned apps for PiCockpit. (Right now PiDoctor, as I've described on the page, already offers some support to monitor overclocking parameters).

What I'll do in any case is add instructions how to do it manually to the page Great idea, thanks again for the feedback!

[dom]

Would you be able to test without the DPI display? (Unlikely that it has an effect, but maybe ...)
I'll also look into it again tomorrow morning, these medium settings are meant to be broadly compatible with most Pis, therefore your feedback is really valuable to me.

Remember that no overclock is 100% guaranteed on all chips with all temperatures and use cases.
If it were we would have have increased the default clock frequency.

I think the best you can do is say a medium overclock should work on, perhaps, 90% of chips.

[aBUGSworstnightmare]

Would you be able to test without the DPI display? (Unlikely that it has an effect, but maybe ...)
I'll also look into it again tomorrow morning, these medium settings are meant to be broadly compatible with most Pis, therefore your feedback is really valuable to me.
Thanks
Max

Will test tomorrow morning and report back! Now I need to think about how to solve the DSI issue ... (other story)

EDIT: just tested (FKMS) with a FHD monitor connected to HDMI and DPI disabled(disconnected: doesn't boot.
Did not test KMS as the result should be the same. Hence, my Pi400 is from the remaining 10% which don't like your settings.

[mike.NY]

Is there a recommended test to run on an overclocked RP4 to make sure it is stable? For windows, there is superPI which computes pi -- the number -- out to millions of decimal places and it compares the results to the known value so if the overclock is unstable, it shows you. I run Raspberry Pi OS 32-bit.

[pi3g]

Is there a recommended test to run on an overclocked RP4 to make sure it is stable? For windows, there is superPI which computes pi -- the number -- out to millions of decimal places and it compares the results to the known value so if the overclock is unstable, it shows you. I run Raspberry Pi OS 32-bit.

I'm researching this right now, and will publish the information along with detailed instructions on

https://picockpit.com/raspberry-pi/over ... pberry-pi/

(currently a work in progress!)

TL;DR:
* Linpack
* memtester
* cpuburn (as recommended by jahboater)

[pi3g]

EDIT: just tested (FKMS) with a FHD monitor connected to HDMI and DPI disabled(disconnected: doesn't boot.
Did not test KMS as the result should be the same. Hence, my Pi400 is from the remaining 10% which don't like your settings.

Try to remove the gpu_freq=750 line, maybe that will help? (Ref:
https://github.com/raspberrypi/firmware ... -578681934
)
(I've tested on my Pi 400 and adding / removing the line makes no difference, it works)

[pi3g]

Remember that no overclock is 100% guaranteed on all chips with all temperatures and use cases.
If it were we would have have increased the default clock frequency.

I think the best you can do is say a medium overclock should work on, perhaps, 90% of chips.

Thanks, Dom, this is a good reminder Would you mind if I quoted it on my overclocking tool's page to set a proper expectation?

[jahboater]

I'm researching this right now, and will publish the information along with detailed instructions on

As its name suggests cpuburn-a53 is best for the Pi's with Cortex-A53 cpu cores.
It does run on Pi4 with its Cortex-A72 cores but doesn't produce such a rapid rise in temperature.
On the original Pi3, in its early days, it would crash the Pi in less than ten seconds!

There is also stress-ng. For example:

Code: Select all

stress-ng --cpu 4 --cpu-method fft

Install it with "sudo apt install stress-ng". Details from "man stress-ng"

For a trivial CPU load without installing anything, try "yes >/dev/null"

Code: Select all

yes >/dev/null & yes >/dev/null & yes>/dev/null & yes >/dev/null &

[dom]

Thanks, Dom, this is a good reminder Would you mind if I quoted it on my overclocking tool's page to set a proper expectation?

That's fine.

[ejolson]

I'm researching this right now, and will publish the information along with detailed instructions on

As its name suggests cpuburn-a53 is best for the Pi's with Cortex-A53 cpu cores.

While general reliability can be important and certainly most important for me, a common use of over clocking is to get a specific application that just wasn't quite fast enough already to run faster.

For example, if a machine emulator for historic hardware doesn't run as fast as the original, over clocking may help. In this case, there is only one binary with a fixed sequence of machine instructions that needs to run without crashing. As a result one can push the clock speeds much further, for example totally breaking all floating point, in order that the specific program of interest runs faster.

Such frequency optimisation that breaks general operations while still allowing a particular program to run is also common for video games. In the extreme case, you could also analyse the operating system to remove troublesome sequences of instructions that lead to a crash. For a start, the CPU-optimised memory copy subroutines in the kernel can be slowed down so overall clock speeds can be increased while maintaining stability.

In my opinion, there are very few cases where the benefit versus cost tradeoff favours over clocking. However, there are obviously some cases where it makes sense and it's nice to have a tool which provides guidance when doing so.

[jahboater]

While general reliability can be important and certainly most important for me, a common use of over clocking is to get a specific application that just wasn't quite fast enough already to run faster.

For example, if a machine emulator for historic hardware doesn't run as fast as the original, over clocking may help. In this case, there is only one binary with a fixed sequence of machine instructions that needs to run without crashing. As a result one can push the clock speeds much further, for example totally breaking all floating point, in order that the specific program of interest runs faster.

That's a good point. But not something I have explored.

In my opinion, there are very few cases where the benefit versus cost tradeoff favours over clocking. However, there are obviously some cases where it makes sense and it's nice to have a tool which provides guidance when doing so.

Every now and again a CPU comes on the market that has huge reserves of stability. That it is, it will usually run with a much lower supply voltage than specified and/or run at a very much higher clock speed than specified.

By the looks of it, the Pi4 has such a CPU. Its stock speed is 1.5GHz, yet most examples are happy running at 2.0 or 2.1 GHz.
The Pi4 in front of me now is unconditionally stable at 2.1GHz and never throttles. I actually run it at 2GHz to give it a safety margin.

This cost me nothing, so the benefit versus cost tradeoff seems favourable.