RPi4 - Power Savings

[soundcheck]

Hi there.

I'd like to collect all kind of power and/or load saving options related to the RPi4.
As most of you know, the RPi4 has a higher power consumption then it's predecessors
and runs at much higher idle temperatures.
Putting the RPi4 into a case or running it with a HAT can an will increase the temperature even further.
RPi 4 cases with integrated fans seem to sell quite well nowadays. If possible I'd like to avoid such a case.
Once in a while I'm running my RPis off batteries. Another reason to get the power consumption down.
And finally I do not intend to buy a set of higher rated, as suggested by the foundation, power supplies.

Below I'd like to list the modification options we had available on the predecessors:

* USB (the entire stack) off
* HDMI off
* LED motherboard off
* LED ethernet off
* WLAN off
* Bluetooth off
* ethernet off
* CPU downclocking
* CPU cores off
* Onboard audio off
* ... perhaps there's more

Not all of these options are causing lower power consumption. However. Disabling stuff that's not being used can be a good idea.
On the other side from my experience it's not always a good idea to e.g. simply remove drivers/modules.
This can prevent from using powersaving features which are only available through a driver.
However. On a RPi 3B+ the biggest power saving I could achieve, was by disabling the entire USB stack (unbind) (running Wifi+HAT).
This action alone brought around 40% (200mA) savings.

Current situation (the way I see it):

Measure 1:
The RPi 4 firmware & drivers are still work-in-progress. Power savings in that area make currently the biggest gains.
With the recent firmware (eeprom) update I measured around around 20% (100mA) savings. That's huge.
To me this upgrade is a must.

Measure x:

...more to come



Let see if we can collect some more ideas and learn how to accomplish these.

[emma1997]

RPi4 has a higher power consumption then it's predecessors

In my battery applications the opposite turned out to be true. Pi4 has ability to draw much lower halt current than my previous models. Set by ee boot code and discovered accidentally when original Pi4 was shipped turning off power by default. Since old models can't do that it caused conflicts with some existing hardware/software. New updates switched back to high power halt by default but can still be changed in ee settings.

The other big savings for me was using the enable pin on cheap DC switchers to power down the Pi completely. About 100x benefit. Much better than MOSFET/relay methods because required a fraction as many components. Not directly part of the Pi itself though.

[soundcheck]

I ran my 3B+ at 230mA (USB/ethernet off @ 800MHz). And now on the PI4 I'm at around 465mA@800MHz.

********

I just tested HDMI.

HDMI is off at boot (probably without devices connected). That's nice.
That was different in the past if I recall it correctly.

Turning HDMI ON adds around 20mA (used to be 10mA).

Code: Select all

##on
sudo tvservice -p

##off
sudo tvservice -o

That seems to be OK.

[soundcheck]

Now I tested the mainboard LEDs.


/boot/config.txt needs to be edited.

NOTE:
Just recently the required overlay naming has been changed! (see below)

Code: Select all

##turn off mainboard LEDs
dtoverlay=act-led

##disable ACT LED
dtparam=act_led_trigger=none
dtparam=act_led_activelow=off
  
##disable PWR LED
dtparam=pwr_led_trigger=none
dtparam=pwr_led_activelow=off

##

No more lightshow, plus < 2mA potential savings per LED.

That also works on the Pi4!

[soundcheck]

Next.

Now come the ethernet jack LEDs.

Good news!
These can also be turned off again. (Didn't work last time I tried)

/boot/config.txt

Code: Select all

##turn off ethernet port LEDs
dtparam=eth_led0=4
dtparam=eth_led1=4

Great another one! Now we've got a totally dark PI. And a couple of mA less.


Just to mention it.

I'm running the latest git kernel 4.19.84 (64bit)
and the latest firmware. All above might not work if you're a bit behind on the SW side.

Code: Select all

~# rpi-eeprom-update 
BOOTLOADER: up-to-date
CURRENT: Tue Sep 10 10:41:50 UTC 2019 (1568112110)
 LATEST: Tue Sep 10 10:41:50 UTC 2019 (1568112110)
VL805: up-to-date
CURRENT: 000137ab
 LATEST: 000137ab

[soundcheck]

On we go.

I now tested Wifi and BT

It's done via /boot/config.txt
As you can see below, also here the overlay naming has changed recently.

Code: Select all

##turn on/ off bluetooth
dtoverlay=disable-bt

##turn on/off wifi
dtoverlay=disable-wifi

By turning off Wifi I measured ~ 45mA savings.
Turning off bluetooth didn't have any impact on that account.

[soundcheck]

One more.

Now comes the ethernet port.

That one behaves quite differently.

All I figured so far is turning it on/off, or perhaps better would be saying putting it to idle and activate it, relates to:

plug or unplug a cable

Unfortunately there is NO overlay called "disable-ethernet".

Below my tests.

Absolute numbers are listed. These relate to my special test setup only!
What matters are the differences.

Code: Select all

~ 506mA - 526mA - cable out - eth0 services on      - eth0 interrupts/s ~ 10
~ 506mA - 526mA - cable out - ifconfig eth0 down  - eth0 interrupts/s = 0

~ 535mA - 603mA - cable in   - eth0 services on       - eth0 interrupts/s ~ 10
~ 535mA - 603mA - cable in   - ifconfig eth0 down   - eth0 interrupts/s = 0

The load, on that idle system, continuously jumped up by ~ 70mA from idle during the test-phase with cable inserted.
as you can see above. That seems a bit add to me.


From what I gather: Without cable the ethernet goes in some kind of idle mode. That's probably pretty much all that can be done
to reduce the load for now.

However. The interface is still causing unnecessary interrupt load with cable disconnected.

By running:

Code: Select all

 
 ifconfig eth0 down 

you'll get rid of all related interrupts. I think doing that is a good idea.

Bottom line.

With a connected cable I see a ~30mA idle increase. That one bounces up regularly to a ~100mA increase. (not sure if that's normal behavior)
The nice thing. Default-wise without cable we're in the rather low-power idle state. Not much more that can be done on that side for now I'd guess.

If you run Wifi, you should not miss to bring eth0 down with ifconfig. The interrupt-load would then disappear by 100%.


I'd love to see an overlay that would disable ethernet altogether.

Perhaps even more savings could be realized that way.

[soundcheck]

Nice progress so far.

The foundation seems to be on track. Most tested mods are working now.

However.

~465mA @ 800MHz is not comparable to the 3B+- though. We talk Wifi and 4cores @idle.

Exactly that scenario I had down to 230mA (actually similar to the PI 3A.)

The key power save mod on my 3B+ installation was the ability to power down the entire USB stack.
That alone brought 200mA savings.

Translating that to the PI4, that'd probably mean to bring down PCI, USB and ethernet altogether.

If anybody knows a way, let us know. The old approach of unbinding the USB driver just doesn't work.

If there's no solution, perhaps considering to introduce new dtoverlay features like:

disable_pci
disable_usb
disable_ethernet

could be a way forward. And that then would also be in line with features like "disable_wifi" etc.

[jamesh]

Interesting results,

Note that the ethernet controller is not the PCIe bus, it's a completely different controller built in to the SoC, so no longer anything to do with USB. If I have time I'll see if it can be turned off.

[soundcheck]

Thx for chiming in.

Yep. I know it's all separated now.
That's why I suggested to think about 3 different "disable_xxx overlays".

Great that you'll have a look it.

[soundcheck]

Let's go on a little.

I looked at the CPU governors. I guess I do not have to explain what these are for.
Just some words. Each of the 6 governors offers a different CPU frequency scheme.
The right choice of the scheme depends on the working conditions each user is running.

The default frequency range is defined by the RPi firmware (don't ask me where exactly)

The frequency range in MHz on the PI4 is fmax=1500 fmin=600.
These can be changed in the /boot/config.txt

By applying e.g.

Code: Select all

arm_freq=600
force_turbo=1

You could nail the PI to a certain frequency and bypass the CPU freq governors.
The governors and their default settings are supplied with the kernel. These governors would still be lingering in the background, even
if you nail the CPUs to a certain frequency.

The available governors can be looked up with:

Code: Select all

cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_governors

On Raspbian, with foundation kernel, we find these:

Code: Select all

conservative 
ondemand
userspace 
powersave 
performance 
schedutil

Default is the "ondemand" governor. That's also defined in the kernel.

Code: Select all

raspberrypi ~ # cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
ondemand
raspberrypi ~ # cat /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_cur_freq
600000

At this point I see

~437mA

current draw in idle operation.


Let's change the game. We'll nail the CPU to highest frequency

Code: Select all

echo "performance" > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor

Code: Select all

raspberrypi ~ # cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
performance
raspberrypi ~ # cat /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_cur_freq
1500000

At this point I see

~485mA

current draw in idle operation.

Bottom line.

These governors can very well make a difference on the quest to get the lowest power PI4 up'n running.
Around 50mA difference under idle conditions IMO is worth considering.
Luckily the default governor is "ondemand". During idle situations you'll basically have the related saving already
in your pocket.

Note: The "powersave" governor would still idle around at 600Mhz. That's why there's no difference to "ondemand"
under idle conditions.

Just to mention it. I do not look at load conditions for now. I'll stay with idle operation for the time being.

[soundcheck]

I just turned the PI4 DRM VC4 V3D driver on and off in /boot/config.txt

Code: Select all

# Enable DRM VC4 V3D driver on top of the dispmanx display stack
dtoverlay=vc4-fkms-v3d
max_framebuffers=2

Having it off saves us

~10mA

under idle conditions.

[soundcheck]

I just tried

1. lowering the number of active CPUs to 2 by adding

Code: Select all

maxcpus=2

to /boot/cmdline.txt


2. disabling onboard audio (also covers HDMI audio)

Code: Select all

dtparam=audio=off

in /boot/config.txt

None of it had any impact on the current draw.

I had hoped that at least the disabled CPUs would enter a kind of deep-sleep state, drawing less power. That's not happening as it seems. Or better. The non active state they are in equals the standard idle state.

[LTolledo]

....and then somebody whispered to me....

".... the best way to save power is not use any power at all.....that means.... turning off the entire (RPi4B) device"

[emma1997]

I think people underestimate the importance of halt mode consumption too. Pi4 can draw considerably less than previous models which is key for long term battery or solar operation. The only case where they can compete is 'turning off the entire (RPi4B)' but that requires external hardware. There seems to be little interest in this.

I'm surprised there's not more activity here in general. Apparently very few are interested in actual power savings. Personally I find this thread very useful and thank soundcheck for all the hard work.

[jdb]

One more.

Now comes the ethernet port.

That one behaves quite differently.

All I figured so far is turning it on/off, or perhaps better would be saying putting it to idle and activate it, relates to:

plug or unplug a cable

Unfortunately there is NO overlay called "disable-ethernet".

Below my tests.

Absolute numbers are listed. These relate to my special test setup only!
What matters are the differences.

Code: Select all

~ 506mA - 526mA - cable out - eth0 services on      - eth0 interrupts/s ~ 10
~ 506mA - 526mA - cable out - ifconfig eth0 down  - eth0 interrupts/s = 0

~ 535mA - 603mA - cable in   - eth0 services on       - eth0 interrupts/s ~ 10
~ 535mA - 603mA - cable in   - ifconfig eth0 down   - eth0 interrupts/s = 0

The load, on that idle system, continuously jumped up by ~ 70mA from idle during the test-phase with cable inserted.
as you can see above. That seems a bit add to me.


From what I gather: Without cable the ethernet goes in some kind of idle mode. That's probably pretty much all that can be done
to reduce the load for now.

However. The interface is still causing unnecessary interrupt load with cable disconnected.

By running:

Code: Select all

 
 ifconfig eth0 down 

you'll get rid of all related interrupts. I think doing that is a good idea.

Bottom line.

With a connected cable I see a ~30mA idle increase. That one bounces up regularly to a ~100mA increase. (not sure if that's normal behavior)
The nice thing. Default-wise without cable we're in the rather low-power idle state. Not much more that can be done on that side for now I'd guess.

If you run Wifi, you should not miss to bring eth0 down with ifconfig. The interrupt-load would then disappear by 100%.


I'd love to see an overlay that would disable ethernet altogether.

Perhaps even more savings could be realized that way.

There are 3 ethernet PHY power states that you enter based on various conditions. The first is active/transmitting - when there is traffic, the PHY is fully powered and sending/receiving data. The second is auto-GREEN mode, where the PHY enters a transparent energy-efficient mode when there is no active traffic (stops sending idle symbols and powers down a lot of the TX circuitry, and enters a sleep mode on the RX side). This requires a compatible Energy-Efficient Ethernet link partner, but most switches implement this feature by default. The third is with the cable unplugged - the PHY enters "energy detect" idle which will completely powers down TX and most of RX, periodically waking the RX side to check for cable insertion.

Ifconfig just shuts down the hardware inside the SoC, so the PHY is still in auto-GREEN mode in this case.

[Imperf3kt]

Sometimes lowering the clock speed won't save you any power. It might appear to, but if that results in your operation taking longer, then the whole point is missed.

[soundcheck]

I'm fully aware of that. It's well known that "low f an high load" is worse than "high f and low load".
High load situations I wouldn't consider the normal situation though.

My main focus therefore is currently on the idle operation.

Saving 100mA or more and not giving away anything is well worth the effort.
Multiply that with million devices out there and you'll look at huge energy savings and a nice green storyline.

[soundcheck]

@jdb

Thx for explaining the ethernet behavior. It pretty much explains what I was measuring.
The question is if there's an low power option beyond "energy detect". Basically an "all off" option.

And. Is there a way to at least stop these Rx wakeups?

***

On the RPI 3B+ - with USB/ethernet enabled and sitting idle I had the device down to around 430mA.
And that's pretty close to my current RPi 4 consumption. It actually almost equals it.

However.
By simply unbinding the USB driver on the RPi 3B+

Code: Select all

echo '1-1' | sudo tee /sys/bus/usb/drivers/usb/unbind

The current draw went down more then 40% to ~230mA idle.
I assumed that this measure knocked the whole USB/ethernet setup out.
I could run it this way because I've just been using WLAN and the GPIOs.

The interesting thing. When doing similar measurements on the RPi 3A,
guess what I've measured ?
Yep. ~230mA idle. Because that USB/ethernet device simply doesn't exist.

I'd love to see a similar option on the RPi4. Additional (optional) 200mA savings would be a major step forward on the quest for maximum Power Savings on the Pi4 .

[soundcheck]

In my battery applications the opposite turned out to be true. Pi4 has ability to draw much lower halt current than my previous models. Set by ee boot code and discovered accidentally when original Pi4 was shipped turning off power by default.

Coming back to the HALT state topic.

If I run "halt" and see just the tiny red LED shining, my meter shows:

~705mA

That's a "burner".

I now tried below boot params:

from default:

Code: Select all

BOOT_UART=0
WAKE_ON_GPIO=1
POWER_OFF_ON_HALT=0
FREEZE_VERSION=0  

to new:

Code: Select all

BOOT_UART=0
WAKE_ON_GPIO=0
POWER_OFF_ON_HALT=1
FREEZE_VERSION=0  

Same situation.

I'm on "pieeprom-2019-09-10.bin"

What am I missing here?

[emma1997]

The original Buster image had a new disable power on halt which gave very low current (20ma IIRC). Older models lacked the ability. Unfortunately it caused potential hardware conflicts on hats with 3.3v but no 5v. Another side effect was GPIO3 turn-on overlay stopped working because CPU isn't powered.

For that and other compatibility reasons the next image reverted back to old 'power stays on' halt. I thought ~200ma and don't recall any 750ma in halt but could be wrong. Definitely huge power savings in virtually all conditions compared to previously. My Pi4 ran much cooler and got even better with each upgrade after that.

One can change it to 'power off' behaviour again using ee editor but I would only bother doing that with my battery/solar setups. Most others like media center etc where conservation don't matter I keep default so the GPIO3 button works.

PS I went back and checked https://www.raspberrypi.org/forums/view ... 3#p1500943 and remember now it was 30ma on the cheap LED meter 24ma on DMM:

[soundcheck]

Here's what I'm looking at in HALT status.

It's a brandnew PI and
latest Raspbian (minimal)
latest RPI kernel (4.19.84-v8+)
latest firmware (tried critical and beta)

RPI4-HALT-current-draw-1024x768.jpg (189.22 KiB) Viewed 45330 times

[emma1997]

I need to go back and check but pretty sure my readings were much less. I upgraded many times but had no reason to check current in that mode lately so maybe new revisions cause increase rather than reduction?

My low power systems are definitely still drawing little because I check the wattmeter weekly and it indicates total average only a few milliamps. Previous Pi3 setups HAD to be checked/charged weekly but now I'm thinking every few months with Pi4. ATM I'm still doing it weekly though until sure things are stable.

[davidcoton]

PS I went back and checked https://www.raspberrypi.org/forums/view ... 3#p1500943 and remember now it was 30ma on the cheap LED meter 24ma on DMM:

But the image shows 0A03 at 12V0! You are not looking at the Pi consumption -- maybe the input to a buck voltage converter?
That equates to 60-70mA at the Pi (if it is just voltage conversion), so still a lot less than 700mA.

[tvjon]

$ vcgencmd version
Nov 18 2019 17:24:43
Copyright (c) 2012 Broadcom
version 1ea9642417358c00d5630ab8a33192570a7b6a4e (clean) (release) (start_x)

$ cat /proc/version
Linux version 4.19.84-v7l+ (dom@buildbot) (gcc version 4.9.3 (crosstool-NG crosstool-ng-1.22.0-88-g8460611)) #1278 SMP Mon Nov 18 14:37:06 GMT 2019

$ cat /etc/os-release
PRETTY_NAME="Raspbian GNU/Linux 10 (buster)"
NAME="Raspbian GNU/Linux"
VERSION_ID="10"
VERSION="10 (buster)"
VERSION_CODENAME=buster
ID=raspbian
ID_LIKE=debian
HOME_URL="http://www.raspbian.org/"
SUPPORT_URL="http://www.raspbian.org/RaspbianForums"
BUG_REPORT_URL="http://www.raspbian.org/RaspbianBugs"


$ cat /etc/rpi-issue
Raspberry Pi reference 2019-06-20
Generated using pi-gen, https://github.com/RPi-Distro/pi-gen, 150e25c4f8123a4c9c63e8dca1b4737fa6c1135c, stage5



BOOT_UART=0
WAKE_ON_GPIO=0
POWER_OFF_ON_HALT=1
FREEZE_VERSION=0



$ sudo halt