With the Teclast F5 (same hardware: BMAX Y11) being my portable little workstation I try to maximize battery life under Linux as much as I can and while doing that try to figure out which are high consumers and how to bring these down.
One of the very first things I found useful was to run powertop and going to the “Tunables” tab and make (most) of them “good”. You may need to experiment a bit here since not all hardware likes to be tuned into lower power states, you may experience strange disconnects or hardware that suddenly stop working. Also quite often issues with suspend and resume may occur. But do not despair! Tuning these and finding the right ones for your hardware will help – quite a bit!
The first one you may want to tune is the SATA link power management. Enabling this should be safe for almost any SATA hardware (controller and drive), it incurs almost no noticeble drawbacks (no performance impact, no latency) but it will save you 0.5W to 1W! This is _massive_! Compared to machine which has an overall power budget of about 5-6W, a full Watt brings it down to 4-5W instead, which can directly translate into an hour more battery run time. So SATA link power management is very good and I wonder why the kernel does not switch it on by default.
This will BTW also bring down the temperature of your SSD significantly. Once of the common problems described especially with the Teclast F5 is that the right handrest can get pretty warm. Under that is the SSD! And enabling the SATA link power management magically bring it down from hot to warm. Something that Windows10 for some reason does not do, it seems. So finally Linux has power management capabilities beyond Win10 – yeah!
A lot of other tweaks can also save some mW here and there but I have not seen anything as significant in one chunk as the SATA link power management. But this does not mean these other tweaks are useless. The main problem with modern Intel CPUs is that as soon as they start to get busy they draw magnitudes more power. An idle Intel CPU like the N4100 of the F5 can got down to far less than 1W (idle = still running, not suspended, but waiting for I/O). So what you have to make sure is that the CPU only leaves this mode when absolutely necessary. What kills us here are all kinds of unsolicited CPU events, like interrupts and especially timers. Everything that regularly wakes up the CPU costs energy. We need to do everything to increase the residency of the CPU in an idle state. So applications with regular animations, blinking cursors, animations on a web page etc. etc. all of that decreases residency in idle and increases power consumption.
I recently got myself a USB type-C power/energy measuring dongle, pretty easy, nothing special but very enlightening. With that you can directly see the impact of every action on the energy budget. With recent kernels (Linux 4.5.x) and curretn Debian (testing / bullseye) and with all tunable items from powertop set to “Good” and about 40% LCD backlight brightness I can get down to about 4.2W on the Teclast F5. You can easily see that whenever the CPU has to do something this quickly goes up to 5W or 6W and quickly falls again after that. There are also some brief moments where it drops below 4.2W.
Another way to increase the residency in lower CPU states is to use the “powersave” CPU frequency scaling governor instead of “ondemand”. Powersave is more conservative in scaling up the CPU than ondemand which results in longer residency in lower frequencies. This should usually have no impact on the usability, you should hardly notice a difference, except with your average energy consumption.
Besides the tunables with powertop there are also some kernel options for some drivers that may help. By default not all power savings are enable in all drivers, I guess not to impact performance or cause problems on some platforms. I have e.g. enabled power saving for the iwlwifi driver:
options iwlwifi power_save=1 led_mode=3
I also disabled the LED output since the F5 does not have a dedicated WiFi LED, so I thought I can turn off this in this case not useful function. In my rc.local I recently added a LED trigger for WiFi RX to use the caps lock LED which I find useful to see if there is WiFi traffic and how much. Since I am traveling a lot recently and sometimes connect to bad WiFis (in terms of bad reception) and then I can see if packets are flowing or not and since I do not use caps lock (but use the caps lock key as compose key instead):
echo "phy0rx" > /sys/class/leds/input0\:\:capslock/trigger
I just recently discovered another driver options which I could verify to help residency of the CPU/GPU, this is so called “fame buffer compression” of the GPU:
options i915 enable_fbc=1 enable_guc=0
With FBC enabled the CPU more often and longer enters a state of just 3.85W in idle, which is impressive! With backlight off it even goes down to 0.95W! Backlight off does not only turn off the backlight but also disables the display controller so the almost 3W is not only consumed by the backlight. As you may have recognized I also disabled the GUC. I tried it once and it will load the GUC and HUC firmware but it turned out to make the graphics unstable – I get GPU timeouts, weird display update problems (parts of closed windows still being displayed), mouse pointer disappearing and so on. So I made sure it does not get enabled or loaded. At some point I will test this again because as described here the GUC can also offer improved power management. Enabling the GUC will also enable the HUC which can offer enhanced H.265 video compression – which I am not very interested in, but well.
While talking about hardware acceleration for video, you can also save a ton of energy when enabling hardware support for video en- and decoding! The CPU usage of MPV drops by 2/3 when enabling it, i.e. for a specific test video from about 35% to about 11%. This directly translates into much longer battery life and less heat. I put this into my .config/mpv/mpv.conf :
# enable hardware acceleration support opengl-backend=wayland hwdec=vaapi
As you can see I run on Wayland, more specifically using GNOME.
Overall I am pretty happy about the power savings right now, though I have the feeling that there is more that can be done. In general, I have to say, I am pretty annoyed by those modern CPUs, Intel in special. They are good at going nothing but as soon as you do just a little bit on them they spike up in energy consumption. The power management schemes implemented by Intel are incredibly complex – just look at all the different states! C states, P states, different levels and combinations and it seems with every generation we get a new extension with another state or suffix. I hope they come to their senses some time and consolidate and simplify this again, which will also help implementing all of that software.