Dynamic over_voltage

Troubleshooting
1

In dietpi-config its possible to set different power profiles. When you set it to medium (1800 Mhz) for example, it sets over_voltage=2.

I was reading a bit about this, and it seems in recent eeprom firmwares this will work counterproductive. Because those can dynamicly change the voltage based on the current CPU frequency. This has the advantage that during idle (clock=600 mhz) no overvoltage is applied, and during heavy load (>1500 Mhz) it is.

So by setting over_voltage=X you override this feature and the voltage will stay fixed, so too high during idle. This will raise the power consumption for no good reason. The only way to trigger this dynamic behaviour is completely leaving out the over_voltage setting (as setting it to 0 will also make it fixed).

So maybe it’s a good idea to have a checkmark in dietpi-config wether you want to use the fixed voltages (controlled by dietpi) or to use a dynamic voltage (controlled by the firmware). Or alternatively just add extra profiles (“medium-dynamic”, “high-dynamic”, etc).

References:

“I do not use over_voltage as the firmware now sets the appropriate voltage automatically for the desired clock speed if you are up to date with latest firmware.”

https://forums.raspberrypi.com/viewtopic.php?p=2114191#p2114191

“Auto adjusting overvoltage” in

1 Like
2

This setting is written to /boot/config.txt, removing it from there should activate the dynamic voltage.

1 Like
3

Are there people who tested this successfully?
And will the empty over_voltage be taken up in future dietpi updates?

4

I can try and test it later today, but not sure how I will track the voltage changes :thinking:

5

I think it can be printed with this command:

vcgencmd measure_volts core

1 Like
6

Yes @Muis the mentioned page gives the following command, so that you can follow the fluctuations.
watch -n1 vcgencmd measure_volts core

1 Like
7

I hope RPI developer did :slight_smile:

I don’t think so. Usually we don’t remove setting done by the user.

I guess it’s applicable for RPI4/5 only right? Maybe something for @MichaIng to think about.

8

Test #1 with this settings:

#-------Overclock-------
initial_turbo=20
arm_freq_min=600

So on my system was no over_voltage set, but watching the vcgncmd command showed, that the voltage didn’t change.

Test #2:
I disabled then these two options, the only enabled options in this block are:

dtoverlay=vc4-kms-v3d,noaudio
dtoverlay=disable-wifi
temp_limit=65

but I don’t think this should impact the outcome.

However I had no change ,I got the whole time volt=0.8563V. :thinking:

9

But did you push the system to 1800 Mhz or higher? Because otherwise its normal that the voltage did not change…

10

Yes, I ran the CPU stresstest.

Edit:

I ran it again with

arm_freq=1800
core_freq=500

and then it changed to 0.9xxxV, so it toggled only between this two states, which is better then nothing :smiley:

1 Like
11

Indeed on RPi 4 and 5 (those with EEPROM) it seems to be possible now to skip over_voltage. Did anyone test whether our profiles run stable, when removing this setting from /boot/config.txt and reboot?

I guess the voltage selected by the firmware will be quite close to what we found to be stable and set, so I do not expect larger differences, but would be still interesting how the firmware sets it and whether it runs stable as well.

Btw, the voltage always jumps between min and max, and AFAIK there are no intermediate steps, so it is possible that you see only one number all the time if there is sufficient background processing keeping the CPU above min/idle frequency.

12

I just tested with the settings stated above, on a RPi 4. But since this is production SBC I won’t run longer stress tests :slight_smile:

13

Any progress on this? It seems like a low-effort modification, and it would be a nice improvement for people to be able to overclock without raising the voltage permanently.

14

It is really not more than that: When you use our profiles, please remove the setting and see whether it runs still stable. If you do not use our profiles, your max voltage is dynamic already. Note that it is not necessarily a benefit. Either the dynamically obtained max voltage is identical, then it is no difference. Or it is higher, then it means higher power consumption and heat emission compared to our profiles. Or it is lower, then then the question is whether it runs stable on all RPi 4/400 revisions, and only then it would be a benefit. So we’d at least need some test results, before removing the hardcoded max voltage from our well tested profiles.

15

During high frequencies, the dynamic voltage will (most likely) be identical or even higher than the fixed voltage from the DietPi profiles, so no benefit.

But during low frequencies (idle), the voltage will (most likely) be lower than the fixed voltage from the DietPi profiles. And as this is where the majority of the Pi’s spend most of their time, the benefit might be quite significant, unless your Pi is always fully loaded.

Now regarding the question of stability: I dont have the time to do extensive testing, but since these dynamic voltages are controlled by the official firmware and set by the Raspberry Pi developers, I have very little doubt that they will run stable. And if they don’t, then we should file a bug-report upstream and let them know.

16

This is not correct. The over_voltage is the “max” voltage, while there is a over_voltage_min for the idle voltage, which we lower at least for some power savings profiles.

But, what I am not sure about, is whether/how much the dynamic voltage scales between those two values. With the settings set, the voltage basically jumps from min to max, at least on RPi 2 and Zero W, IIRC. Need to test on RPi 5. So if dynamic voltage makes better use of intermediate values, then you might be overall right. I mean, my home server is x1000 times more in absolute idle frequency state, than any other:

root@micha:~# cat /sys/devices/system/cpu/cpufreq/policy0/stats/time_in_state
600000 113113198
700000 112669
800000 74408
900000 70882
1000000 564591

So here, all that matters is over_voltage_min. And with dynamic voltage, I would only be able to set over_voltage_delta, which affects min+max voltage, hence I would not be able to keep the min voltage low + the max voltage sufficiently high (which is required). Using more powerful hardware as planned (currently RPi 2, plan to switch to NanoPi R6C), this will become “worse”. However, any more regularly busy system would of course benefit, if the intermediate CPU frequencies would also result in intermediate CPU voltage.

There is no officially supported overclocking profile, and even raspi-config does not provide overclocking for anything after RPi 2. Hence the dynamic voltage is not meant to be stable for any overclocking scenario, but most importantly to cover the defaults. You cannot make a bug report if the system does not run stable after overclocking it :wink:. You either lower values, or raise voltage. Probably there are tests/threads regarding this for RPi 5 on the RPi forum, so we could take results from there. Interesting would be, whether over_voltage_delta needed to be set at some point, for the system to remain stable on higher clock rates. This would mean higher idle voltage as well.

17

Your explanation is a bit different than the references I linked in the OP. For example the section about “auto adjusting voltage” said:

“You can always set the over_voltage parameter. Keep in mind, it’s a fixed value, always selected, even when the cores are running idle at arm_freq_min.”

That is a bit contrary to how you describe that setting, but maybe that article is wrong.

Also, in the forum post I linked, users report that they can run their Pi4 at 2375 Mhz (!) while using this dynamic voltage (and no over_voltage at all). So it seemed to work great for overclocking.

And lastly, I am not suggesting to remove all the existing DietPi profiles. Just to also add some dynamic profiles, so that people can decide for themselves, and if it turns out they dont run stable, they can always be removed.

18

Jep, about that part, the article is definitely wrong. Even the RPi docs state it differently/correctly. Or what do you think the purpose of over_voltage_min would be? :wink:

IMO we have already too many profiles :smile:. If it takes too long to looks through and decide which to take, then one can faster just set the values in config.txt directly. If it is stable across the range of our profiles, I’d instead just skip the over_voltage value and leave them otherwise unchanged. I anyway want to rework it for RPi 4: Since arm_boost=1 exists for a while, which basically turns newer RPi 4 models into RPi 400, frequency-wise, I want to:

  • Add arm_boot=1 OOTB.
  • Find a way to reliably detect whether it is supported by the used RPi 4 model, e.g. check whether scaling frequency 1800 MHz exists while vcgencmd get_config arm_boost returns 1.
  • Show RPi 400 profiles, in case.

And in the same turn, we could remove over_voltage, and probably the over_voltage_min profile as well.

When implementing the RPi 5 profiles, we can skip that right from the start.

Btw, since I have no RPi 4, but you seem to be interested in this, it would be nice if you could test and compare our profiles, with over_voltage left in place, and after removing it. What I am also interested in is the actual resulting voltage numbers:

vcgencmd measure_volts

Since the command itself raises CPU usage, and schedutil governor reacts very fast, you will need to switch to powersafe governor to see the minimum voltage, and probably conservative to better see the intermediate steps, performance to see the max voltage. To see all available frequencies:

cat /sys/devices/system/cpu/cpufreq/policy0/scaling_available_frequencies

And playing around with the governors and voltage readout command, one should be able to generate a table, showing which voltage is used for which frequency, and also whether over_voltage_min still has an effect, or breaks DVFS, like over_voltage does.