This is my guide to the Pi 5 under/overclocking; I will show how I achieve it and how to use piStats (which will explain why I added some options).
As you may have noticed it’s very easy to OC to 3 GHz but it’s also very likely that it’s not stable as you thought.
Let’s start from the basic settings for config.txt:
isp_freq=910
sdram_freq_min=4267
Don’t specify anything else (about clocks and voltages) which is not covered here, it’ll make things worse.
-
isp_freq: This is bizarre but I need it on the dietPi image to get full bandwidth on network I/O, not with the Pi OS image. If in idle the Pi answers in more than 1ms to a ping from a host on the same network switch, you have this issue. Anyway it doesn’t hurt specifying it, it’s the default clock
-
sdram_freq_min: Supposedly this is doing nothing. Maybe, I can’t check it myself. It’s mandatory otherwise if you lower the arm cores minimum clock below 1500 MHz, it’ll become unstable. You MUST NOT set sdram_freq and you MUST shutdown and unplug for 10 seconds the power supply (otherwise the Pi 5 will keep doing weird stuff). Doesn’t hurt setting it
At the beginning I will address the first step which is underclocking of the minimum arm core clocks.
It’s a common topic and also quite important and risky.
But first let’s talk about the Broadcom SOC in the Pi 5 and the two Pi 5 I’ll use for this guide.
The BCM2712, like its predecessor, is using DVFS (Dynamic Voltage and Frequency Scaling).
This means, in a few words, that is scaling frequency and voltages based on load and temperature.
Like desktop processors, it’s tested and “serialized” during the manufacturing process.
It will have a map of voltages, the lowest that can run, stable at the standard clocks with a temperature limit of 75c.
The map is quite conservative as the Pi is also meant to run without any heatsink on top, even if I guess it’s not really a good idea with the Pi 5.
Out of this process you get “good bins” and “bad bins”; the good ones will run stable at lower voltages and thus lower temps.
You definitely want to have a good bin; the problem you could face is that they are more tricky to OC.
I have 2 x Pi 5, one is a good bin and the other isn’t:
-
Good one “playpi5”: Pi 5 4GB on a passive cooling case EDATEC, running a minimal Pi OS
-
Bad one “DietPi5”: Pi 5 8GB on an official case with the active cooling heatsink, running dietPi 9.0.2 with some small background load
The best case for passive cooling and the worst for active.
I’ll show you how to understand if it’s a good bin and how to handle it.
When the maximum clock is raised to 3 GHz this “good bin map” can become an issue.
UNDER CLOCKING OF THE MINIMUM ARM CORE FREQUENCY
Let’s address the 3 basic questions; is it safe, what is the gain and should I do it.
First question is easy to address; it’s not safe.
There’s no guarantee that you will not end up in issues and you should definitely avoid it in some specific use cases.
Lowering the minimum clocks means that the latency of the system in idle will be higher.
If you are using your Pi as a small NAS server maybe that’s not an issue.
But if you are actually doing something sensitive in idle, like using a HAT to record some metrics, that can become a problem.
The first thing that will fail in idle is the network I/O so you will likely experience some packet loss as first sign of instability.
The gain is a slightly less power consumption in idle; about 300-350mW.
This is quite considerable if you run on battery but the main advantage is a lower idle temperature; about 2c less.
With the passive case this can be even bigger, up to 6c.
This is not always true. You will get a lower power consumption only in idle, true idle.
If you are running dietPi with some constant background load, like running kubernetes, the Pi will almost never be in idle.
Also OC clocks will make it boost from idle to higher clock bins resulting in even less lower idle states.
The pcore reported by piStats will be higher cause just the PMIC query is enough to bring it out of idle and spike power consumption.
These very frequent ups & downs are not the best of course, you may want to leave it as default with OC even with a light background load.
You may end up with the opposite of the intended result, higher power consumption and idle temperature.
In case you may found it unstable below 1500 or unstable at the default settings, you can try to add a few mW of delta or set over_voltage_min to 5 to 7.
Try with over_voltage_delta in a range of 1000 to 4000 and see if you can improve.
In some cases you’ll have to stick to the default or even increasing it from 1500.
But now the next step is testing that it’s working reliably in idle; how to achieve it?
Most of the times unfortunately you’ll find out when things goes wrong.
Something dies unexpectedly, like a piStats in a ssh shell, filesystem corruption, random reboots, packet loss on the network, etc.
Packet loss monitoring is the easiest way to go.
TESTING FOR STABILITY
You should test for stability your Pi5 even with default settings. it doesn’t hurt.
The first thing that will start acting weird is the network I/O.
The basic test for stability, especially for idling, is to monitoring packet loss via ICMP.
If you have any Windows host it’ll make things much easier.
Both he Pi4 and Pi5 when unstable they’ll drop packets and connections from Windows hosts.
Eventually will happen also to Linux hosts but much less frequently and later.
Pinging the Pi5 from a Windows host will show you an unstable configuration in seconds, avoiding long testing sessions.
I use Nirsoft PingInfoView, you can use anything else that has the same metrics:
What you need to monitor is:
-
Failed Count: the Pi will always need the same time to boot, larger deviation than the usual it’s a sign the configuration is unstable (eg. 11 packets lost before the reboot is completed instead of 8-9 is a sign of instability). Random packet loss is a sign of instability, monitor for weeks to be 100% sure
-
Average Ping Time: the average ping time should be 0 or 1 if connected to the same ethernet switch, higher response times in idle means instability
-
Maximum Ping Time: it should never go up above 20-30 ms, even when running the most CPU intensive stress test, compare with default settings in doubt. 70-150 ms means instability.
Sometimes, you need to reboot twice or three times to get it stable after a simple change in the config.txt.
It’s recommended to unplug the USB plug as much as often possible and let it switch off for 10 seconds.
I have another Pi always connected and also a NAS Server; I open a screen session via SSH where I leave it pinging the Pi to monitor and also other control hosts (like the other Pi, the switch, the router) to confirm if a packet loss was a general issue or not.
You should use as many hosts as possible to monitor via ICMP as long as possible. For the Pi4, I’ve left the NAS pining for 2 months to be 100% sure.
Running on the Pi you will need the following:
- piStats: Release v1.16 · mann1x/piStats · GitHub
- stress-ng: install with “sudo apt install stress-ng”
- phoronix test suite: Release Phoronix Test Suite 10.8.4 · phoronix-test-suite/phoronix-test-suite · GitHub
Since the CPU changes it’s frequency and voltage dynamically we need to test also dynamic loads.
The classic full core stress test load is needed but it’s not going to tell you if the system is stable.
A full static workload it’s not the heaviest in this case and not the most difficult to pass.
Remember to set first the right cpu governor.
schedutil if you want the best performance/power consumption (but you may want to use a different one).
You can set it via dietpi-launcher → dietpi-config → Performance → CPU Governor
Otherwise on Pi OS edit /etc/default/cpu_governor and set:
CPU_DEFAULT_GOVERNOR="schedutil"
HOW TO CHECK IDLE
You can’t and won’t do much on the Pi, as you must keep it in idle.
Best way is to monitor for very long time via an ICMP ping and see if you catch a packet loss.
I also always leave a screen session running piStats every 10 seconds and come back every now and then to check if it’s still running.
Check you don’t see unusual lag on SSH connections.
HOW TO CHECK LOW BACKGROUND ACTIVITY
In theory these lower clocks are the easiest to handle for the SOC but it’s not always true.
Sometimes a too optimistic map could set a voltage too low.
Best way to test is to use dietPi, install microk8s and enable it.
Just the standard pods running in the background will create the perfect workload.
Otherwise, use stress-ng and leave it in background for a cheap simulation:
stress-ng -c 3 -l 5 --sequential 0 -t 0
Monitor the same as idle.
HOW TO CHECK STATIC HIGH LOAD
You can set run a stress test via dietpi-launcher → dietpi-config → Tools → Stress Test
CPU & RAM at least and run it for at least 1h.
Or you can run stress-ng via command line, there are a lot of options like:
stress-ng -c 4 --iomix 8 -m 8
HOW TO CHECK DYNAMIC HIGH LOAD
Easiest way to test is using phoronix test suite.
Install the recommended tests:
phoronix-test-suite install build-apache build-linux-kernel build-nodejs
Setup your batch-run defaults first with:
phoronix-test-suite batch-setup
Then you can run the tests with:
export FORCE_TIMES_TO_RUN=1; phoronix-test-suite batch-run build-nodejs
Always set explicitly the runs otherwise it will start repeating them for even dozen of times if there are outliers in the results.
The tests:
- build-apache: quick and first to run
- build-linux-kernel: run 3 times for a total of over 1h40m, after one successful run of build-nodejs
- build-nodejs: the most intensive test, pass 1 run and go over 3 build-linux-kernel, make a final 3 runs test to be sure
DETERMINING THE BIN QUALITY
As a default config.txt values I will use:
isp_freq=910
v3d_freq=910
sdram_freq_min=4267
Since I can also monitor the power consumption, I’ll start with the good bin with default settings:
mannix@playpi5:~$ ./piStats.sh -joq -d 10.1 -asvc
piStats v1.16: playpi5 [Pi 5 Model B Rev 1.0]
Rel: 6.1.0-rpi8-rpi-2712 Ver: #1 SMP PREEMPT Debian 1:6.1.73-1+rpt1 (2024-01-25)
entering continuous mode refresh every 10.1 seconds...
temp clock cpufreq pcore vcore vsoc r1clk r1volt r1temp
39.5 1600 1500/1600 0.6780 0.7200 0.7200 5.432 0.7200 40.0
40.6 1500 1600/1600 0.6383 0.7200 0.7200 5.425 0.7200 39.5
40.6 1600 1500/1500 0.6254 0.7200 0.7200 5.425 0.7200 40.0
40.0 1600 1600/1500 0.6321 0.7200 0.7200 5.425 0.7600 39.5
40.0 1600 1600/1500 0.6785 0.7200 0.7650 5.432 0.7200 39.5
39.5 1600 1600/1500 0.6379 0.7200 0.7650 5.425 0.7200 40.0
40.0 1600 1600/1600 0.6254 0.7200 0.7200 5.432 0.7600 40.6
40.6 1500 1600/1600 0.6782 0.7200 0.7650 5.425 0.7200 39.5
39.5 1500 1600/1600 0.6321 0.7600 0.7200 5.425 0.7200 39.5
40.0 1500 1600/1600 0.6319 0.7600 0.7200 5.432 0.7200 39.5
40.0 1600 1600/1600 0.6252 0.7600 0.7200 5.432 0.7200 40.0
40.0 1500 1600/1600 0.6257 0.7200 0.7200 5.432 0.7200 40.6
40.0 1500 1600/1600 0.5801 0.7600 0.7200 5.425 0.7600 40.6
40.0 1600 1600/1600 0.5803 0.7600 0.7200 5.432 0.7600 40.0
40.6 1600 1600/1600 0.6446 0.7600 0.7650 5.432 0.7200 40.0
Excellent temperature, the actual power consumption is around 2500 mW jumping quite often up to 2800-3200 mW.
Here with the minimum clock at 600 MHz:
mannix@playpi5:~$ ./piStats.sh -joq -d 10.1 -asvc
piStats v1.16: playpi5 [Pi 5 Model B Rev 1.0]
Rel: 6.1.0-rpi8-rpi-2712 Ver: #1 SMP PREEMPT Debian 1:6.1.73-1+rpt1 (2024-01-25)
entering continuous mode refresh every 10.1 seconds...
temp clock cpufreq pcore vcore vsoc r1clk r1volt r1temp
40.6 1600 1600/1500 0.8458 0.8039 0.8050 5.432 0.7544 40.0
40.6 1500 1400/1600 0.8578 0.7957 0.7650 6.342 0.7957 40.0
40.6 1600 1100/1500 0.8509 0.7957 0.8050 5.432 0.7957 40.0
40.6 1500 1600/1500 0.8386 0.8039 0.7650 6.388 0.8039 40.0
40.0 1600 1500/1600 0.8386 0.8039 0.8050 5.425 0.7957 40.0
41.1 1500 1600/1600 0.8506 0.7957 0.7650 5.425 0.7200 40.6
40.0 1500 1600/1500 0.8963 0.7957 0.7650 5.834 0.7544 40.6
40.6 1500 1600/1600 0.8314 0.8039 0.8000 6.065 0.7709 40.6
40.6 1500 1500/1600 0.8240 0.8039 0.7650 6.335 0.7957 40.0
40.6 1600 1600/1500 0.8386 0.8039 0.8050 5.425 0.8039 40.6
41.1 1500 1600/1600 0.8243 0.8039 0.8000 6.335 0.7957 40.0
Power consumption is around 2200 mW and is jumping not so often to 2500-2700 mW.
Temperature is almost identical because at this ambient and with this good case, the 300 mW less are not making a difference.
You will see a higher power consumption because the very frequent switching of the clocks together with the low resolution of the PMIC sampling, will make the reading noisy and less accurate.
Always compares PMIC readings from equal clocks.
Just consider that in idle, only if the system has a very light load, it will consume a bit lees.
Let’s see the other one with dietPi running how it fares:
root@DietPi5:~# pistats -joq -d 10.1 -asvc
piStats v1.16: DietPi5 [Pi 5 Model B Rev 1.0]
Rel: 6.1.0-rpi8-rpi-2712 Ver: #1 SMP PREEMPT Debian 1:6.1.73-1+rpt1 (2024-01-25)
entering continuous mode refresh every 10.1 seconds...
temp clock cpufreq fan pcore vcore vsoc r1clk r1volt r1temp
57.1 1500 1500/1600 3367 0.7289 0.8427 0.8050 5.109 0.7200 57.1
57.6 1500 1500/1600 3325 0.6915 0.7200 0.7200 5.109 0.7200 57.6
57.1 1500 1500/1600 3364 0.6183 0.8014 0.7200 5.109 0.7200 57.1
56.5 1500 1500/1600 3362 0.6254 0.8014 0.7200 5.109 0.7200 56.5
56.5 1500 1500/1600 3360 0.5352 0.8014 0.8050 5.109 0.7200 56.5
57.1 1500 1500/1600 3355 0.6254 0.7200 0.8050 5.109 0.7200 57.6
57.1 1600 1500/1600 3356 0.7062 0.7200 0.8050 5.109 0.7200 57.1
57.1 1500 1600/1600 3354 0.6188 0.8014 0.8050 5.109 0.7200 57.1
58.2 1600 1500/1600 3348 0.6911 0.7200 0.7200 5.109 0.7200 57.1
57.1 1600 1500/1600 3347 0.5285 0.8014 0.7200 5.109 0.8014 56.5
55.4 1600 1500/1600 3346 0.6841 0.7200 0.7200 5.109 0.7200 57.1
56.5 1500 1500/1600 3345 0.6121 0.8014 0.8050 5.109 0.7200 56.5
57.1 1600 1500/1600 3348 0.6243 0.8014 0.7200 5.109 0.7200 57.1
57.1 1500 1500/1600 3347 0.6990 0.8014 0.7200 5.109 0.7200 56.5
Very similar, except for the much higher temperature.
Again let’s see the temperature with the minimum clock at 600 MHz:
root@DietPi5:~# pistats -joq -d 10.1 -asvc
piStats v1.16: DietPi5 [Pi 5 Model B Rev 1.0]
Rel: 6.1.0-rpi8-rpi-2712 Ver: #1 SMP PREEMPT Debian 1:6.1.73-1+rpt1 (2024-01-25)
entering continuous mode refresh every 10.1 seconds...
temp clock cpufreq fan pcore vcore vsoc r1clk r1volt r1temp
56.5 1500 1500/1500 3396 0.8446 0.8428 0.8100 5.946 0.8098 56.5
56.5 1500 1500/1500 3390 1.2483 0.8428 0.8350 5.109 0.7767 57.1
56.5 1500 1500/1500 3381 0.8449 0.8428 0.8350 5.109 0.8346 56.5
57.1 1500 1500/1500 3374 0.8521 0.8428 0.8350 5.794 0.7767 56.5
56.5 1600 1500/1500 3367 0.8444 0.8428 0.8050 5.109 0.8098 57.6
56.0 600 1500/1500 3358 0.8776 0.8346 0.8350 5.794 0.7767 56.5
56.0 1500 1500/1500 3355 0.8855 0.8263 0.8050 5.109 0.8428 57.1
56.5 1500 1500/1500 3351 0.8521 0.8263 0.8350 5.109 0.8098 56.5
55.4 1500 1500/1500 3351 0.8366 0.8263 0.8350 5.801 0.7767 56.5
56.5 1500 1500/1500 3348 0.8518 0.8428 0.8100 5.109 0.8346 56.5
56.0 1500 1600/1600 3342 0.7345 0.8346 0.8350 6.375 0.8346 55.4
56.0 1600 1500/1500 3340 0.8377 0.8428 0.8350 5.102 0.8346 55.4
56.5 1500 1600/1600 3337 0.8441 0.8428 0.8450 5.109 0.8346 57.1
56.0 1600 1500/1500 3335 0.8925 0.8346 0.8450 5.102 0.8098 56.5
Here we can see the small improvement, 1-2c at best.
Is it worth it? Up to you to decide, if in doubt don’t touch it.
Now let’s use stress-ng to check the binning, run it on a different session:
stress-ng -c 4
While monitoring with piStats, here playpi5:
mannix@playpi5:~$ ./piStats.sh -joq -d 0.1 -asvc
piStats v1.16: playpi5 [Pi 5 Model B Rev 1.0]
Rel: 6.1.0-rpi8-rpi-2712 Ver: #1 SMP PREEMPT Debian 1:6.1.73-1+rpt1 (2024-01-25)
entering continuous mode refresh every 0.1 seconds...
temp clock cpufreq pcore vcore vsoc r1clk r1volt r1temp
49.9 2400 2400/2400 4.1930 0.8700 0.8700 7.014 0.8700 49.9
49.9 2400 2400/2400 4.2345 0.8700 0.8700 7.021 0.8700 49.9
And here’s dietpi5:
root@DietPi5:~# pistats -joq -d 10.1 -asvc
piStats v1.16: DietPi5 [Pi 5 Model B Rev 1.0]
Rel: 6.1.0-rpi8-rpi-2712 Ver: #1 SMP PREEMPT Debian 1:6.1.73-1+rpt1 (2024-01-25)
entering continuous mode refresh every 10.1 seconds...
temp clock cpufreq fan pcore vcore vsoc r1clk r1volt r1temp
66.4 2400 2400/2400 6690 4.3012 0.9089 0.9100 7.060 0.9089 64.8
Now let’s use piStats to see how it behaves with build-nodejs:
temp clock cpufreq fan pcore vcore vsoc r1clk r1volt r1temp
73.6 2400 2400/2400 10574 4.2248 0.9089 0.9100 7.047 0.9089 72.5
72.5 2400 2400/2400 10589 4.3063 0.9089 0.9100 7.054 0.9089 73.0
73.6 2400 2400/2400 10582 4.1220 0.9089 0.9100 7.054 0.9089 73.0
73.6 2400 2400/2400 10589 4.3471 0.9089 0.9100 7.054 0.9089 73.6
72.5 2400 2400/2400 10589 4.8772 0.9089 0.9100 7.054 0.9089 72.5
73.0 2400 2400/2400 10582 4.3690 0.9089 0.9100 7.054 0.9089 73.0
As expected it doesn’t throttle and keeps the SOC below 75c under stress.
Now the playpi5:
temp clock cpufreq pcore vcore vsoc r1clk r1volt r1temp
53.2 2400 2400/2400 4.2045 0.8700 0.8700 7.014 0.8700 53.8
53.2 2400 2400/2400 4.1257 0.8700 0.8700 7.014 0.8700 52.7
53.8 2400 2400/2400 3.8663 0.8700 0.8700 7.014 0.8700 53.2
54.3 2400 2400/2400 4.3112 0.8700 0.8700 7.014 0.8700 53.2
52.1 2400 2400/2400 4.1852 0.8700 0.8700 7.014 0.8700 53.2
53.2 2400 2400/2400 4.4648 0.8700 0.8700 7.014 0.8700 53.8
53.2 2400 2400/2400 3.7118 0.8700 0.8700 7.014 0.8700 53.2
53.8 2400 2400/2400 3.8474 0.8700 0.8700 7.014 0.8700 53.2
54.3 2400 2400/2400 3.9509 0.8700 0.8700 7.014 0.8700 53.2
53.2 2400 2400/2400 4.1969 0.8700 0.8700 7.007 0.8700 53.8
53.2 2400 2400/2400 4.0412 0.8700 0.8700 7.014 0.8700 53.8
53.8 2400 2400/2400 3.9328 0.8700 0.8700 7.014 0.8700 54.3
53.8 2400 2400/2400 3.9538 0.8700 0.8700 7.014 0.8700 52.7
52.7 2400 2400/2400 4.0861 0.8700 0.8700 7.014 0.8700 53.2
53.2 2400 2400/2400 4.1826 0.8700 0.8700 7.007 0.8700 53.8
53.8 2400 2400/2400 3.8474 0.8700 0.8700 7.014 0.8700 53.2
53.2 2400 2400/2400 4.0558 0.8700 0.8700 7.014 0.8700 53.8
Lower voltages and thus lower power consumption; with a good bin the temperature is even less a problem.
A good passive case is more than enough for standard clocks.
Things will become more complex with overclocking.
Let’s see what happens if we check the voltages at 3 GHz while running stress-ng.
A generic `over_voltage_delta=20000’ is used to boot.
3.0 GHz voltages on dietpi5:
temp clock cpufreq fan pcore vcore vsoc r1clk r1volt r1temp
71.9 3000 3000/3000 6699 6.6587 1.0000 1.0000 7.759 1.0000 71.4
And 3.0 GHz voltages on playpi5:
temp clock cpufreq pcore vcore vsoc r1clk r1volt r1temp
56.5 3000 3000/3000 6.4736 0.9750 0.9750 7.864 0.9750 56.5
Now the problem is which voltages will be selected for the new bins, between 2400 and 3000 MHz.
You may be wondering if 0.975V is enough for playpi5 to run at 3 GHz and the answer is no.
Let’s see what you should do to find the right delta.
Basically, you have to raise the value in config.txt until it’s stable.
You can raise it each time by 2000 and 1000 to fine-tune at the end.
After you have found a delta that can pass a basic stress test, you need to find out which is the range that works best.
For this you need a quick test that is easy to pass.
Always keep open piStats and monitor the Pi: ‘piStats -joq -d 0.1 -asvc’
These are the best options and you can run it with a 0.1s period as you don’t care about the added load.
Save as much as possible the logs and the idle temperatures.
On my dietpi5 a delta of 22mV has worse idle temperatures than 28mV; you need to carefully check each time.
Let’s find a stable `over_voltage_delta’.
Run build-apache for 3 runs and find the upper and lower ranges for the delta where it starts failing more quickly.
Test with all the delta until you get a range where it works better eg. between 26000 and 40000
Now fine-tune the delta with build-linux-kernel and try to pass at least one run.
Here the working range should decrease quite a bit eg. between 35000 and 38000
Once passed build-linux-kernel, move to the next test; build-nodejs.
This is really heavy and if you can pass one it’s already a big win.
You need to save the log of piStats so you can later review and compare it.
Some settings will behave better than others when the temperature starts to raise.
To be 100% sure you need to switch off and on a few times the Pi and pass it again every time.
When you are really sure then you can make a final pass with 3 runs for each test.
Chances it’ll be so straightforward are very thin.
You can easily end up, no matter what delta value you try, to miserably crash while running build-nodejs.
This can happen if you don’t have an outstanding active cooling or you just happen to have a good bin.
Which is exactly the scenario for both my Pi5.
We have 2 more options for the overclocking which are temp_limit and over_voltage_min.
The over_voltage_min function is similar to setting a manual LLC on a desktop PC BIOS.
While I could find a stable delta for playpi5 with the good bin, 38mV, it wasn’t stable.
Reason why was pretty obvious rebooting and testing every time the bin quality.
At each reboot the voltages are mapped again and every time was something wildly different.
Setting a manual over_voltage_min fixes this issue and the voltages will always be negotiated in a small window.
For instance with playpi5 at 7 the vcore is always between 0.900 and 0.950V and the vsoc fixed at 0.950V.
A settings from 5 to 7 is preferable; at 8 the temperatures are much higher than 7 and below 5 it doesn’t really have a noticeable effect.
Higher the value, lower the delta between the vcore and vsoc.
For dietpi5 I’ve set it at 6 with a delta of 31mV.
I could pass all the stress testing at 29mV but I had to raise it cause I was still having random packet loss in idle.
Despite that I couldn’t yet pass build-nodejs on dietpi5.
I noticed the r1clk throttling hard (it has a sensible variation when throttling starts) at 75c while on playpi5 it was throttling at 80c.
The official case is definitely undersized for the 3 GHz.
Limiting to 80c solved the issued.
In general is better to reduce the clocks instead of relying on thermal throttling.
Thermal throttling is always bad and the Broadcom implementation is very bad.
A 75c thermal limit will likely cause this with build-nodejs:
temp clock cpufreq fan pcore vcore vsoc r1clk r1volt r1temp
73.0 600 3000/3000 10482 5.8879 0.7200 0.9750 7.759 0.9942 71.9
75.2 2735 3000/3000 10489 1.7265 1.0000 1.0000 7.607 0.9715 73.6
73.0 2845 3000/3000 10496 5.7256 0.9715 0.9800 7.759 1.0000 72.5
74.7 600 3000/3000 10489 4.9991 0.9790 0.9800 7.726 0.9866 73.6
73.6 600 3000/3000 10496 6.1548 0.9715 0.9800 7.686 0.9715 74.7
74.1 2955 3000/3000 10496 5.4465 0.9942 0.7200 7.568 0.7200 75.7
74.7 2900 3000/3000 10485 4.7005 0.9715 0.9750 7.759 0.9942 73.0
74.1 2790 3000/3000 10482 5.9837 0.9715 0.9900 7.607 0.9715 74.7
73.6 600 3000/3000 10485 5.2927 0.9790 1.0000 7.719 0.9942 73.0
73.6 600 3000/3000 10485 4.9903 0.9866 0.7200 7.713 0.7200 75.2
74.1 2900 3000/3000 10482 5.0824 0.9866 0.7200 5.135 0.9942 73.0
74.1 2845 3000/3000 10482 6.5376 0.9715 0.9950 7.601 0.9790 74.1
73.0 2955 3000/3000 10493 4.5135 0.9715 0.9800 7.568 0.9715 74.7
74.7 2845 3000/3000 10489 1.6608 0.9942 0.9950 7.759 1.0000 73.0
74.7 2955 3000/3000 10489 6.0387 0.9715 0.9800 7.607 0.9715 74.7
75.2 600 3000/3000 10496 1.6852 0.9715 1.0000 7.568 0.7200 75.2
74.1 2735 3000/3000 10489 4.4183 0.9866 1.0000 7.752 0.9866 73.6
74.7 2900 3000/3000 10482 1.2596 1.0000 0.9750 7.759 1.0000 73.6
73.0 2955 3000/3000 10485 6.4282 0.9715 0.9900 7.759 1.0000 71.9
74.7 600 3000/3000 10482 4.8756 0.9715 0.9800 5.129 1.0000 72.5
As you can see the clock is throttled, not anymore a solid 3000, and it’s often dropping to 600.
The pcore is also very often down to 1 Watt.
A good throttling, check your logs with PiStats, will have very long runs at throttled speed and a few throttling events at 600 and then again a long run at throttled speed.
Just avoid the temp_limit below 80c and always check how it’s throttling.
Some settings are better than others and will throttle smoother, others (even with a lower delta or min) will be worse.
My playpi5, while passing successfully build-nodejs wat 85c, was throttled so hard at 75c that it was failing the compilation.
Don’t forget to keep pinging the Pi for weeks to be sure it’s safely overclocked!
I will later dive on underclocking and undervolting.