Raspberry Pi 5 cannot overclock beyond 3.0GHz due to firmware limit(?)
youmukonpaku1337 opened this issue · comments
Is this the right place for my bug report?
This issue seems to be firmware-related, as the clocking is done through it.
Describe the bug
Setting arm_freq
beyond 3000 works fine, but vcgencmd measure_clock arm
reports 3000 MHz, while software like Geekbench and btop detect it as the clock set by arm_freq, e.g. 3.1GHz
To reproduce
- Set
arm_freq
beyond 3000, and an according over_voltage_delta - Reboot, and run
vcgencmd measure_clock arm
- Check with something else, like btop or Geekbench
- Clocks will be mismatched and vcgencmd will only report 3.0GHz
Expected behaviour
The Pi is actually clocked beyond 3.0GHz and both vcgencmd and other software report it as such
Actual behaviour
The Pi is only clocked to 3.0GHz, and vcgencmd reports it as such, but software sees it as set in arm_freq
System
https://pastebin.com/U2KCBBnD
- Which model of Raspberry Pi?
Pi 5 - Which OS and version (
cat /etc/rpi-issue
)?
Raspberry Pi reference 2023-12-05 Generated using pi-gen, https://github.com/RPi-Distro/pi-gen, 70cd6f2a1e34d07f5cba7047aea5b92457372e05, stage4
- Which firmware version (
vcgencmd version
)?
2024/02/16 15:28:41 Copyright (c) 2012 Broadcom version 4c845bd3 (release) (embedded)
- Which kernel version (
uname -a
)?
Linux q-raspi5 6.6.17-v8-16k+ #1735 SMP PREEMPT Wed Feb 21 14:45:17 GMT 2024 aarch64 GNU/Linux
Logs
dmesg output is in the raspinfo paste
Additional context
If this is relevant, I used rpi-update to update to latest kernel and firmware version, no change
I have also set debian sources in sources.list to testing/trixie
I'm pretty sure the Pi 5 can handle clocks beyond 3.0GHz as it's extremely stable at that clock, so that as well
That's what we've been told is the limit of the PLL by Broadcom.
I've got a todo item to investigate what happens when this is exceeded, but it's not high on the priority list.
That's what we've been told is the limit of the PLL by Broadcom.
I've got a todo item to investigate what happens when this is exceeded, but it's not high on the priority list.
ah i see, that's sad, hope it gets fixed soon! would love to run my pi at absurd clocks
I've removed the 3GHz limit, and attached a zip file (you can flash it to an sdcard with rpi-imager) you can test.
Make sure you have no critical (unbacked up) data on the Pi you are testing.
Let me know if you succeed in going above 3GHz.
I could boot at 3.1GHz (and vcgencmd measure_clock arm
confirmed that) but my Pi would crash when stressed.
that's actually awesome, tysm, i assume i just flash it to an sd card that isnt the one i have raspbian on and boot?
Yes - use a spare card.
alright, thanks, will test asap
Dangit how did I not see this issue before now :)
Going to see if I accidentally nuke my 'blessed' Pi 5 (the only one I've been able to get to 3.0 GHz so far).
Dangit how did I not see this issue before now :)
Going to see if I accidentally nuke my 'blessed' Pi 5 (the only one I've been able to get to 3.0 GHz so far).
LMAO
Petition to make 3.14GHz the new upper limit in the firmware.
So I've been trying to get a Geekbench 6 run to complete at 3.14 GHz, testing higher and higher over_voltage_delta
(with force_turbo
off and on), and so far can't quite hack it.
I wound up capturing this from dmesg:
[ 326.258634] ------------[ cut here ]------------
[ 326.258637] Firmware transaction timeout
[ 326.258646] WARNING: CPU: 3 PID: 31 at drivers/firmware/raspberrypi.c:67 rpi_firmware_property_list+0x204/0x270
[ 326.258654] Modules linked in: algif_hash algif_skcipher af_alg bnep vc4 snd_soc_hdmi_codec binfmt_misc aes_ce_blk drm_display_helper cec aes_ce_cipher drm_dma_helper drm_kms_helper hci_uart ghash_ce snd_soc_core btbcm gf128mul snd_compress sha2_ce snd_pcm_dmaengine brcmfmac sha256_arm64 sha1_ce bluetooth snd_pcm brcmutil snd_timer snd rpivid_hevc(C) cfg80211 v4l2_mem2mem pisp_be videobuf2_dma_contig videobuf2_memops videobuf2_v4l2 ecdh_generic fb_sys_fops ecc syscopyarea sysfillrect sysimgblt rfkill libaes videobuf2_common v3d videodev raspberrypi_hwmon mc gpu_sched drm_shmem_helper raspberrypi_gpiomem rp1_adc pwm_fan nvmem_rmem uio_pdrv_genirq uio fuse drm drm_panel_orientation_quirks backlight dm_mod ip_tables x_tables ipv6 spidev i2c_brcmstb spi_bcm2835 gpio_keys
[ 326.258699] CPU: 3 PID: 31 Comm: kworker/3:0 Tainted: G C 6.1.0-rpi7-rpi-2712 #1 Debian 1:6.1.63-1+rpt1
[ 326.258702] Hardware name: Raspberry Pi 5 Model B Rev 1.0 (DT)
client_loop: send disconnect: Broken pipe
And the cursor blinks on the external display, but SSH goes away.
Checking the actual voltage:
$ vcgencmd measure_volts
volt=1.0000V
So I'm wondering if there's any way to boost that further, or if 1.0000V
is the hard limit for the cores?
I should note I have an Argon THRML 60-RC and an additional giant 140mm Noctua fan blowing over everything, fan set to full blast (pinctrl FAN_PWM op dl
— for some reason my custom setting for fan_temp0
through 4 to run the speed at 255 doesn't seem to make a difference).
Yay! Got one run in at 3.14 GHz with:
over_voltage=8
arm_freq=3140
force_turbo=1
Honestly not sure if the over_voltage vs over_voltage_delta made a difference or if I just got lucky on this run and unlucky on the other runs.
Here's the result: https://browser.geekbench.com/v6/cpu/5314274
And a video! https://www.youtube.com/watch?v=TTIkZBsVJyA
HELL YEAH!!!
I've tried flashing, but I just see the boot menu. I tried two different drives with the bootloader but nothing happens?
I've removed the 3GHz limit, and attached a zip file (you can flash it to an sdcard with rpi-imager) you can test.
Make sure you have no critical (unbacked up) data on the Pi you are testing. Let me know if you succeed in going above 3GHz.
I could boot at 3.1GHz (and
vcgencmd measure_clock arm
confirmed that) but my Pi would crash when stressed.
How was it made?
With a C compiler, mostly. @popcornmix is a Raspberry Pi engineer.
Yay! Got one run in at 3.14 GHz with:
over_voltage=8 arm_freq=3140 force_turbo=1
Honestly not sure if the over_voltage vs over_voltage_delta made a difference or if I just got lucky on this run and unlucky on the other runs.
Here's the result: https://browser.geekbench.com/v6/cpu/5314274
And a video! https://www.youtube.com/watch?v=TTIkZBsVJyA
i might try breaking 1k singlecore >:)
Here's the result: https://browser.geekbench.com/v6/cpu/5314274
That's your single/multi scores: 967 / 1793 (does really nobody notice how wrong this benchmark is when a quad core CPU scores multi-threaded not even twice as much as single-threaded?)
And here's one outperforming your setup at 972 / 1847 clocking the cores only at 3.0 GHz: https://browser.geekbench.com/v6/cpu/5312673
Forget about the displayed 3.2 GHz, that's just what the cpufreq
driver thinks and on any RPi it has no clue about real clockspeeds. Geekbench on ARM with Linux starting from v4.2 on measures and also reports the clockspeeds in the warmup phase: https://browser.geekbench.com/v6/cpu/5312673.gb6 (you need a GB browser account to access these raw data files)
"processor_frequency": {
"frequencies": [
2994,
2992,
2992,
...
2993,
2997,
2991
]
So what's different on that system? Maybe simply the user switched to performance
cpufreq governor prior to firing up Geekbench? Maybe memory access is faster compared to @geerlingguy's run where the CPU cores were being measured at ~3133 MHz which is to be expected at the configured 3140 MHz?
BTW: when talking about overclocking it's also a lot about DFVS since 'usually' higher clockspeeds need significantly higher supply voltages. One would expect to see a curve like this (but more exponentially growing at the right side in case of 'overclocking'):
With RPi 5 (at least with latest ThreadX/firmware 30cc5f37 / 2024/01/05 15:57:40) it looks either linear or funny:
arm_freq=3000
:
1500 MHz 720.0 mV
1600 MHz 760.0 mV
1700 MHz 775.0 mV
1800 MHz 790.0 mV
1900 MHz 800.0 mV
2000 MHz 815.0 mV
2100 MHz 830.0 mV
2200 MHz 845.0 mV
2300 MHz 855.0 mV
2400 MHz 870.0 mV
2500 MHz 885.0 mV
2600 MHz 900.0 mV
2700 MHz 910.0 mV
2800 MHz 925.0 mV
2900 MHz 940.0 mV
3000 MHz 955.0 mV
arm_freq=3000
combined with over_voltage=4
:
1500 MHz 720.0 mV
1600 MHz 860.0 mV
1700 MHz 875.0 mV
1800 MHz 885.0 mV
1900 MHz 900.0 mV
2000 MHz 915.0 mV
2100 MHz 930.0 mV
2200 MHz 940.0 mV
2300 MHz 955.0 mV
2400 MHz 970.0 mV
2500 MHz 970.0 mV
2600 MHz 970.0 mV
2700 MHz 970.0 mV
2800 MHz 970.0 mV
2900 MHz 970.0 mV
3000 MHz 970.0 mV
arm_freq=3000
combined with over_voltage_delta=50000
:
1500 MHz 720.0 mV
1600 MHz 805.0 mV
1700 MHz 820.0 mV
1800 MHz 835.0 mV
1900 MHz 850.0 mV
2000 MHz 860.0 mV
2100 MHz 875.0 mV
2200 MHz 890.0 mV
2300 MHz 905.0 mV
2400 MHz 915.0 mV
2500 MHz 930.0 mV
2600 MHz 945.0 mV
2700 MHz 960.0 mV
2800 MHz 970.0 mV
2900 MHz 985.0 mV
3000 MHz 1000.0 mV
It always starts at 720 mV for the lowest OPP (and this even when you adjust this with for example arm_freq_min=1000
) and then some algorithm 'draws' a straight line up to the highest OPP except for the over_voltage
setting where things get really weird since overvolting low OPP while keeping the same supply voltage for the 'overclocked' OPP is quite the opposite of what's expected when having silicon behaviour in mind.
Also the 'line drawing' behaviour starting at the lowest OPP ends up with strange behaviour. When not adjusting any of the arm_freq
ThreadX settings the 1500 MHz OPP gets 720 mV. But when setting arm_freq_min=1000
the line gets drawn with a similar algorithm but now the 1500 MHz OPP is at 775 mV and not 720 mV any more:
1000 MHz 720.0 mV
1100 MHz 730.0 mV
1200 MHz 740.0 mV
1300 MHz 750.0 mV
1400 MHz 765.0 mV
1500 MHz 775.0 mV
1600 MHz 785.0 mV
1700 MHz 795.0 mV
...
One would expect that
- the supply voltage of a certain clockspeed being a HW property and based on silicon testings with some safety headroom. Each cpufreq OPP has an ideal supply voltage (as low as possible to save energy and also as high as needed to allow for stable operation) that shouldn't 'move around' when adjusting
arm_freq
settings - ideally the SoC manufacturer allows for AVS due to 'silicon lottery' and as such 'lower quality' chips will automagically be driven with slightly higher supply voltages and optionally top cpufreq OPP denied if the supply voltage would exceed a critical limit
- the DVFS OPP painting a curve (linear/flat on the left side and then exponentially growing for the higher/highest OPP) and not a straight line
@popcornmix are the 1st and 3rd issue somewhat addressed with the new ThreadX/firmware version you provided above?
A few comments. The idle point of 0.72V is fixed for all boards.
Below that voltage internal RAMs become unreliable, so you can't go lower than that however low the clock go.
Each chip has a unique base voltage (vpred), determined by querying ring oscillators.
This is added to a fixed slope that increases with frequency.
True, the real curve may not be flat, but over the non-overclocked range, it's pretty close to flat.
We don't characterise the overclocked range - you are on your own and can manually adjust with over_voltage_delta.
over_voltage
is deprecated. It doesn't take into account vpred.
over_voltage_delta
is preferred.
There is a 1V ceiling that currently can't be exceeded.
interesting. anyway, gotta break 1k in geekbench for the sillies, will see if i can manage maaaaybe 3.3ghz?
Edit: haven't seen the answers above before firing up this comment
@popcornmix are the 1st and 3rd issue somewhat addressed with the new ThreadX/firmware version you provided above?
Nope, just tested with arm_freq=3100
and over_voltage_delta=100000
. The upper voltage limit with ThreadX build 4d574a2e is (still?) 1000mV and the algorithm 'drawing' a linear line is also still in place:
1500 MHz 720.0 mV
1600 MHz 855.0 mV
1700 MHz 870.0 mV
1800 MHz 885.0 mV
1900 MHz 900.0 mV
2000 MHz 910.0 mV
2100 MHz 925.0 mV
2200 MHz 940.0 mV
2300 MHz 955.0 mV
2400 MHz 965.0 mV
2500 MHz 980.0 mV
2600 MHz 995.0 mV
2700 MHz 1000.0 mV
2800 MHz 1000.0 mV
2900 MHz 1000.0 mV
3000 MHz 1000.0 mV
3100 MHz 1000.0 mV
As such results as expected: when 1.0V can't be exceeded (most probably for a good reason) allowing for higher clockspeeds is just asking for trouble :)
@ThomasKaiser - Yeah, sadly it looks like 1V is the upper limit, but maybe some fancy (highly destructive) hacking around can surpass it.
Regarding that other 3.0 GHz score beating my Geekbench 6 run, I wonder if it running the 4GB RAM part has anything to do with it (I think that was a 4 GB model). I know in some microbenchmarks, at least at some point the 4 GB boards ran faster than the 8 GB boards, when memory was important to the run.
I only have two 4 GB Pi 5s, and neither goes beyond 2.8 GHz reliably, so I can't confirm much.
i wonder, is there no way to OC memory on a pi? i saw some firmware opts for it but havent checked much
Regarding that other 3.0 GHz score beating my Geekbench 6 run, I wonder if it running the 4GB RAM part has anything to do with it (I think that was a 4 GB model)
I'm currently testing around with my own RPi 5B (also 4 GB) and got an even better score at 3050 MHz: 975/2022. Since I'm also starting GB only through sbc-bench -G
there's always memory latency measurement also done and I see here variations. My first try with 3050 MHz showed these ramlat scores:
Executing ramlat on cpu0 (Cortex-A76), results in ns:
size: 1x32 2x32 1x64 2x64 1xPTR 2xPTR 4xPTR 8xPTR
4k: 1.350 1.313 1.312 1.312 1.312 1.312 1.312 2.498
8k: 1.312 1.312 1.312 1.312 1.312 1.312 1.316 2.561
16k: 1.319 1.313 1.314 1.315 1.312 1.313 1.314 2.556
32k: 1.312 1.312 1.312 1.312 1.312 1.315 1.312 2.577
64k: 1.312 1.313 1.315 1.312 1.312 1.312 1.313 2.558
128k: 3.935 3.935 3.944 3.935 3.938 4.412 5.722 9.945
256k: 4.247 3.961 4.250 3.952 4.110 4.489 5.622 9.955
512k: 7.360 7.278 7.052 7.280 7.034 8.428 9.196 13.87
1024k: 13.22 12.90 12.87 12.88 13.05 13.45 15.19 22.17
2048k: 17.04 15.88 16.77 15.88 25.23 16.79 18.92 26.45
4096k: 67.59 61.33 67.46 61.59 68.93 68.06 80.18 101.3
8192k: 93.54 106.5 97.65 87.53 94.22 90.86 101.5 126.8
16384k: 104.1 101.3 103.9 101.8 103.6 104.9 126.2 127.4
32768k: 116.2 113.8 114.5 113.6 115.3 114.5 115.7 119.3
65536k: 118.7 117.5 127.3 117.3 118.6 117.7 118.7 121.1
131072k: 120.0 118.9 119.9 118.8 120.0 128.6 119.4 120.2
While now again testing with 3050 MHz I'm getting both worse latency and GB scores (955/1948 on average):
Executing ramlat on cpu0 (Cortex-A76), results in ns:
size: 1x32 2x32 1x64 2x64 1xPTR 2xPTR 4xPTR 8xPTR
4k: 1.324 1.314 1.312 1.312 1.312 1.312 1.312 2.500
8k: 1.312 1.312 1.312 1.312 1.312 1.312 1.312 2.555
16k: 1.318 1.312 1.313 1.312 1.312 1.312 1.312 2.555
32k: 1.312 1.312 1.312 1.312 1.312 1.312 1.312 2.579
64k: 1.312 1.312 1.312 1.312 1.313 1.313 1.312 2.558
128k: 3.935 3.936 3.936 3.935 3.935 4.468 5.765 9.939
256k: 3.939 3.936 3.962 3.976 4.007 4.437 5.633 9.944
512k: 7.443 7.492 7.521 7.490 7.456 8.786 8.990 13.97
1024k: 14.53 13.29 13.76 13.28 13.25 13.76 15.46 23.43
2048k: 26.47 27.03 26.91 26.98 41.58 25.73 27.83 34.22
4096k: 69.95 61.53 68.19 61.56 70.88 68.41 79.23 100.5
8192k: 94.90 107.5 100.6 88.62 96.38 96.22 105.3 135.3
16384k: 105.1 101.9 104.2 101.5 104.8 105.9 117.9 144.4
32768k: 117.5 115.9 116.9 115.7 117.1 115.6 119.2 129.1
65536k: 119.7 118.7 128.3 118.5 119.9 118.9 120.4 125.6
131072k: 121.9 121.1 121.8 121.1 121.9 128.1 120.9 123.8
Some of the individual benchmarks are rather sensitive to memory speed, some not (I tested this with a RK3588 board where one can easily adjust memory clock between 528 and 2112 MHz from userspace though forgot where I documented the results – maybe on your site somewhere in the comments). At least with my tests it looks like this comparing both runs:
https://browser.geekbench.com/v6/cpu/compare/5326061?baseline=5324484
Asides different temperatures (in the first run my 'monster cooler' kept temperatures below/around 40°C and then I tried higher temps as per your recommendation wrt stability) I don't see any settings that might have changed and affect the behaviour...
As such would be interesting if you could compare memory bandwidth between 4GB/8GB models (an sbc-bench
will already do it). And as a side note: with more recent ThreadX versions memory access seems to be faster than in the beginning.
Edit: my conclusions wrt memory speed affecting fluctuating GB scores were BS since the first run ('with lower memory latency') also produced scores that vary substantially: https://browser.geekbench.com/v6/cpu/compare/5324361?baseline=5324484 – unfortunately GB also has some sort of random number generator in place when generating scores.
Edit 2: confirmed. Another run at 3050 MHz with sbc-bench -G
(always executing GB twice for a reason) ends up with the same picture: standard deviation way too high or in other words: Geekbench 6 on ARM and especially RISC-V sucks:
First run:
Single-Core Score 949
Multi-Core Score 1960
Second run:
Single-Core Score 973
Multi-Core Score 2010
https://browser.geekbench.com/v6/cpu/compare/5326624?baseline=5326716
interesting..
with more recent ThreadX versions memory access seems to be faster than in the beginning.
Actually there is no ThreadX on a Pi5. The bootloader code runs with no RTOS.
ThreadX is used by start*.elf
on pi0-4.
SDRAM performance has been improved recently by scaling back refresh with (sdram) temperature
See: #1854 (comment)
with more recent ThreadX versions memory access seems to be faster than in the beginning.
Actually there is no ThreadX on a Pi5. The bootloader code runs with no RTOS. ThreadX is used by
start*.elf
on pi0-4.SDRAM performance has been improved recently by scaling back refresh with (sdram) temperature See: #1854 (comment)
is it possible to use both the test bootloader and the patched firmware?
@ThomasKaiser You keep referring to ThreadX, but there is no ThreadX running on a Pi 5.
nevermind, looks like the sdram change was merged
Actually there is no ThreadX on a Pi5. The bootloader code runs with no RTOS.
ThreadX is used by start*.elf on pi0-4.
@popcornmix Then what's servicing mailbox requests?
The bootloader code with no RTOS.
gotta break 1k in geekbench for the sillies, will see if i can manage maaaaybe 3.3ghz?
Nope, my board scored 1k already at 3080 MHz. In case of interest I'll share the recipe (but it's really simple, since all you need is a) setting the cpufreq governor to performance and b) patience since Geekbench on ARM and especially on RISC-V is such an unbelievable nonsense).
This is what I've done (setting arm_freq=3080
and over_voltage_delta=100000
, rebooting, setting cpufreq governor to performance
, bringing my 12 bucks 'monster cooler' into position and then simply executing the benchmark 10 times in a row):
echo performance | sudo tee /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor
for i in 1 2 3 4 5 6 7 8 9 10 ; do geekbench6 ; done
Worst vs. best GB score as follows:
https://browser.geekbench.com/v6/cpu/compare/5329465?baseline=5330184
While we all (should) know that Geekbench has a standard deviation way too high the interesting bit in this series is that the scores generally got better over time (6% more over time is a lot).
On other platforms I experienced stuff like display controller not detecting a display as such shutting down the whole display/GPU IP blocks after 10 minutes which ended up with way higher memory bandwidth for the CPU after that amount of time. But here I'm clueless what's happening...
gotta break 1k in geekbench for the sillies, will see if i can manage maaaaybe 3.3ghz?
Nope, my board scored 1k already at 3080 MHz. In case of interest I'll share the recipe (but it's really simple, since all you need is a) setting the cpufreq governor to performance and b) patience since Geekbench on ARM and especially on RISC-V is such an unbelievable nonsense).
:despair: how about 1100
My board (at 3080 MHz) also outperforms the best GB5 score (at 3100 MHz) so far in this mode (headless and uptime +1 hour): https://browser.geekbench.com/v5/cpu/compare/22321360?baseline=22322650
This former best score must also use @popcornmix's latest 'bootloader' release since exceeding 3.0 GHz (though I don't understand how something can be called a bootloader that sits permanently in the background and is accessible via vcgencmd
– I really hope we're not dealing with UEFI running in the background now?!)
While GB5 numbers are a bit more related to real-world workloads (hey, a quad-core A76 scores multi-threaded almost 3 times as much as single-threaded and not just ~2 times as with GB6) I still don't understand what's going on.
Using sbc-bench
in the same scenario numbers remain the same (with passive benchmarking everything that differs by not at least 5% has to be considered identical):
uptime | Clockspeed | 7-zip multi | 7-zip single | AES | memcpy | memset |
---|---|---|---|---|---|---|
few minutes | 3080 MHz | 13670 | 3980 | 1756000 | 5990 | 17260 |
+1 hour | 3080 MHz | 13760 | 3998 | 1755570 | 6120 | 17290 |
:despair: seems like my pi crashes at multi-core photo library in geekbench at 3.2ghz, i get "hwmon undervoltage detected" although my power supply is fine and is supplying enough..
is it not enough overvoltage? i have overvoltage delta set to 500000 (since it can't use that much anyway i think)
oh yeah... i should set governor to perf as well hmm
how about 1100
How about understanding that 'overclocking' an ARM SoC is almost always nonsense?
There's a sweet spot wrt energy efficiency (though IMHO not on RPI 5 with actual firmware DVFS settings) and while a quad-core A76 like BroadCom's Muskoka platform might be able to operate at or above 3.0 GHz it makes absolutely no sense other than generating silly benchmark scores.
Disclaimer: when we were able to buy RPi 5 (vaporware here in Germany for almost half a year) I thought setting arm_freq=3000
would be the way to go on every RPi 5. Not knowing back then that we're winners of the 'silicon lottery' since majority of BCM2712 can't cope with even lower clockspeeds.
And the most important part (people eager to get 'scores' always forget) is: you're entering 'data loss / data corruption' territory. There's a fixed 1000mV limit and I personally achieved already zram filesystem corruption issues with latest 'firmware' above 3.0 GHz.
i get "hwmon undervoltage detected" although my power supply is fine and is supplying enough..
No, it obviously is not and you (like vast majority of RPi users – 101%) confuse voltage with amperage.
And BTW: use sbc-bench -G
instead since this will monitor benchmark execution and reports your RPi 5 not running at 3.x GHz as you might think but just 1500 MHz once 'undervoltage detected'. It's really funny how every RPi from day one suffered from this 5V undervoltage drama since users don't understand the 5V cable resistance problem (called Ohm's law) :)
i get "hwmon undervoltage detected" although my power supply is fine and is supplying enough..
No, it obviously is not and you (like vast majority of RPi users – 101%) confuse voltage with amperage.
considering that this power supply is the single one that ran this pi for weeks at 3.0GHz with no undervoltage (others spammed that message quite frequently), i'd consider it to be fine, besides, it's PD and has a max output of 30w (15v 2a) or 27w (9v 3a)
okay this happens at 3150mhz as well, on geekbench multicore photo library I get 2 "hwmon undervoltage detected" and then the pi crashes... it's only specifically that benchmark, cpuburn and the other geekbench benches do not have issues
has a max output of 30w (15v 2a) or 27w (9v 3a)
Who cares? At least not your RPi 5 since only negotiating 5V modes with whatever USB PD power brick you own. And at 5V it becomes crucial whether the power brick has a fixed cable (allowing it to compensate voltage drops) or not (undervoltage danger). Am out now since too much spam for this issue already...
fixed cable? huh, never heard of that, maybe that might be the issue
@youmukonpaku1337 - There are a few power supplies capable of supplying the clean 5V/5A the Pi 5 requires. Having a cable soldered straight into the power adapter reduces a tiny amount of insertion loss you get with any adapter with a detachable cable. And the longer the cable, the greater the voltage drop (that's why Pi's own 27W adapter has a slightly shorter cable now).
The Pi 5 only negotiates at 5V, nothing higher, so to get the best performance you need a good power adapter that supplies at least 3A (ideally 5A), has a short-ish cable, is permanently attached, and has thick enough individual copper wires to cause as little voltage drop as possible. With all that, you'll have better stability—and can run more off the USB ports if you desire.
Some of those things aren't a big concern when running the Pi 5 at the default 2.4 GHz clock, but when you push limits, it's best to start from the best foundation (power-wise) possible, just like no heatsink is fine for many use cases, but overclocking, you should add a fan and/or good heatsink.
yeah i get that, i thought PD power supplies could negotiate most amp/volt setups as long as its under total wattage... hm ill take a look at whether i can find another one
looks like there are no power supplies with 5v5a support here outside of >100w chargers (20v5a and such) which i unfortunately cannot afford... not fun, why does the pi use out of spec pd lmao
looks like with an acefast a45 charger i got past geekbench without the pi undervolting so, guess im lucky :p
https://browser.geekbench.com/v6/cpu/5344754
managed a 3.175GHz run with a new power supply - unfortunately get undervoltage at 3.2GHz and a kernel panic at 3.3, it'd be great to go past 1v
That's lower than Jeff's score at 3140 MHz (especially multi so you suffered in that try already from unreported undervoltage / frequency capping). And my 4GB board's results at 3080 MHz outperform both your tries ('tries' not 'devices').
And the whole overclocking approach makes absolutely no sense other than generating silly numbers since we're running into data corruption issues due to the fixed 1000mV supply voltage ceiling.
Linpack/OpenBLAS is pretty capable of detecting undervoltage issues – the journey started 8 years ago with RPi 3B: https://forums.raspberrypi.com/viewtopic.php?t=139712
We (me being a former member of linux-sunxi community) used the tool to generate DVFS OPP tables for some Allwinner SoCs and the thing still works:
sudo apt install libmpich-dev
git clone https://github.com/ThomasKaiser/StabilityTester
cd StabilityTester
./xhpl64
And while my board is able to generate silly GB6 scores above 3.0 GHz I get FAILED
results from Linpack for these clockspeeds so with some safety headroom my board is not able to work RELIABLY above ~2.7 GHz...
That's lower than Jeff's score at 3140 MHz (especially multi so you suffered in that try already from unreported undervoltage / frequency capping). And my 4GB board's results at 3080 MHz outperform both your tries ('tries' not 'devices').
And the whole overclocking approach makes absolutely no sense other than generating silly numbers since we're running into data corruption issues due to the fixed 1000mV supply voltage ceiling.
Linpack/OpenBLAS is pretty capable of detecting undervoltage issues – the journey started 8 years ago with RPi 3B: https://forums.raspberrypi.com/viewtopic.php?t=139712
We (me being a former member of linux-sunxi community) used the tool to generate DVFS OPP tables for some Allwinner SoCs and the thing still works:
sudo apt install libmpich-dev git clone https://github.com/ThomasKaiser/StabilityTester cd StabilityTester ./xhpl64
And while my board is able to generate silly GB6 scores above 3.0 GHz I get
FAILED
results from Linpack for these clockspeeds so with some safety headroom my board is not able to work RELIABLY above ~2.7 GHz...
linux-sunxi? oh, i was actually in the irc for quite a while, was porting an a13 ebook :p
ill take a look at linpack/openblas and ill also see if i can get an official pi power supply, thanks
no undervoltage was reported in dmesg, funnily enough
no undervoltage was reported in dmesg, funnily enough
That message indicates that the PMIC (power management chjp) has detected that the 5V input has dropped significantly (something like 4.7V). It can't detect the 3.3V line being dragged lower, or localised undervoltage around a high current consumer (e.g. the ARM cores under heavy load, the WiFi chip, etc.).
no undervoltage was reported in dmesg, funnily enough
That message indicates that the PMIC (power management chjp) has detected that the 5V input has dropped significantly (something like 4.7V). It can't detect the 3.3V line being dragged lower, or localised undervoltage around a high current consumer (e.g. the ARM cores under heavy load, the WiFi chip, etc.).
oh, i see, i guess i really need an official pi power supply then. maybe i can pull off some extremely high clocks that way lol