Tips on improving standby time?

I have measured my standby time with modem off, WiFi on, bluetooth off and it is pretty much exactly 9hrs from 100% to 4% (it apparently shut down at 4%). During these hours I did not use the phone at all. The phone was around 5m from the router with no walls in between laying still. So it should be easily reproducible for others if they wish.

The processes that seem to be running the most are “tracker-miner-fs” which I’d like to disable since I don’t search my filesystem very often.

I just ran this simple script in a “screen” session and after the phone died I checked the written file.

#!/bin/sh
while : ; do
    battery=$(cat /sys/class/power_supply/max170xx_battery/capacity)
    echo $(date --iso-8601=seconds): ${battery}% | tee -a bat_log
    sleep 60
done

Any tips on how to improve this?

Also, occasionally lollypop seems to scan through my library even though there’s nothing reading/writing any files in that folder and it takes quite a lot CPU usage since I have a music collection of 100GB on my SD-card. During my standby test I made sure that lollypop was not running though so it was not impacted then, just wondering if anyone has experienced this.

3 Likes

Maybe not the answer you’re looking for, but in case you’re not aware of it, standby time should dramatically increase once suspend is implemented



2 Likes

If you are using 5 GHz WiFi then it may be worth trying 2.4 GHz WiFi instead.

Start the script in a cron job to commence after, say, 8 hours - so that the script does not itself affect the outcome as much.

I wasn’t exactly clear on the purpose of the script. It’s giving you the data for a graph of battery percentage v. time. If you just want to detect the shutdown then uptime | cut -d, -f1 may be adequate.

Any particular reason to use | tee -a bat_log rather than >>bat_log

Thanks for the tip. I hadn’t noticed that.

My collection is not that large because I have so far only copied over a fraction of it.

Also, the energy expended is likely to be proportional to the number of tracks, not the total size. That is, it could take more energy on a collection that has more tracks and less total size but uses lower quality MP3 e.g. 128 kbit/sec v. fewer tracks, greater total size but uses higher quality MP3 e.g. 320 kbit/sec or FLAC. etc. etc.

I used to have the same problem on my main server but then I think the media server code changed to ‘watch’ the directory and hence ‘scan on change’ rather than re-reading the entire directory tree every X hours (effectively polling for changes).

1 Like

Yeah I’ve read that. But I’ve had the phone now for multiple months and it’s still not integrated on byzantium so I’m not holding my breath.

Good point, unfortunately I have configured my router to have the same name for 2.4Ghz and 5Ghz so devices can decide themselves when they want to go from 2.4Ghz to 5Ghz so it’s not an easy thing to change (in my experience most devices handle that pretty badly though, so I should probably go back to how I used to have it anyway). Maybe I can force the L5 to only use 2.4Ghz though somehow? Will investigate.

I guess that’s an optimization. Since the device doesn’t suspend though, I don’t think that my tiny script does much of a difference in terms of power (compared to e.g. tracker-miner-fs which draws 0-8% of CPU according to htop while my script is consistently at 0%).

Both of these were mostly due to testing before taking it through a whole battery cycle. Could be optimized as well of course, but I doubt it would make much of a difference.

I have 84GB FLAC files and 50GB MP3 files, so I guess the amount of files is a bit less than most people since it’s such a significant amount of FLACs.

Now that you say it, I do have the files synced with syncthing and maybe they are slightly modifying the files somehow? I don’t think so, but it might be worth investigating.

Syncthing wasn’t running while doing the battery test though, so it did not have an impact to the test. I only run it occasionally when I know that I want to sync certain files.

This is important information sharing. But I’m wondering could a reasonably anonymized crowd-app be made to gather data from volunteers to better optimize all the different variations? I like the idea of Carat (by several universities around the world), which has its code available in git (also to install to androids without play, if need be). Could it (or something else) be used or done to help this endeavor?

2 Likes

I take it you don’t have a router that allows multiple SSIDs per band.

In other words, you could advertise SSID “foo” on both bands but advertise SSID “foo-low” only on 2.4 GHz - and then configure the Librem 5 to use “foo-low” and leave all your other devices on “foo”.

Or see next.

Yes. See the earlier discussion: Traveling Experiences

1 Like

I do, I run OpenWRT. I just found it to sound nice if the device would choose the best band depending on range. After realizing that it does not work to well on many devices though I regret that decision, but to change it have to re-connect all my devices which would take a lot of time and it mostly works OK.

Thanks for the link, was able to do that! Might try measuring the standby time again and see how much longer it can survive on 2.4Ghz.

Yup, Wi-Fi on 2.4GHz takes less power than 5GHz on the Redpine card.

In case it works with your AP, you can also try enabling the power saving mode, which should reduce power consumption even further:

sudo iw dev wlan0 set power_save on

Keep in mind that it’s not enabled by default because it can degrade or even completely break the connection on some APs. On some, it may get better after adding enabled_uapsd=1 to the line that starts with options redpine_91x in /etc/modprobe.d/librem5-devkit.conf and rebooting, but on some it may even make it worse, so YMMV.

In case it works fine for you and you want to enable it by default, you can create /etc/NetworkManager/conf.d/99-wifi-powersave.conf:

[connection]
# Values are 0 (use default), 1 (ignore/don't touch), 2 (disable) or 3 (enable).
wifi.powersave = 3
6 Likes

OK, serves me right for implicitly asking a question as a negative. :wink: I can’t tell whether you do or don’t have multiple SSID support.

If you can have multiple SSIDs then you don’t need to re-connect anything except the Librem 5 (as described above).

Indeed. For example, mine. I had powersave enabled on a client device (not the Librem 5! - just talking in general terms) and WiFi would work only until it powersaved and then it would cease working until the next reboot and would also often hang the shutdown. So, um, quite inconvenient.

I have done as you show - except choosing ‘2’ to disable.

Hopefully everybody else’s mileage does vary.

2 is the default that’s already defined in /usr/lib/NetworkManager/conf.d/90-wifi-powersave.conf (I told to create a new one in /etc as this one may get overwritten with updates).

Sorry, I should have made explicit: This is on Ubuntu and I am pretty sure that it defaults to ‘3’, and it caused me no end of problems.

Regardless, the message is agreed: Enable WiFi powersave cautiously.

In particular, you may not be able to disable it remotely if your only way in is via WiFi(!). So on the Librem 5 that would probably mean: undo the change locally using the command line e.g. for convenience keep a copy of the original .conf file / a copy with powersave disabled so that reverting the change is only a matter of cp or mv or similar.

It would be great if the Librem 5 would adopt Gnome power settings defaults and implement settings system wide:

  1. Power Saver (set power save options across all modules, including lower screen brightness, maybe automatic screen brightness = on, turn screen off in one minute and fade more quickly, CPU throttle, limit RAM use, limit background processes (like fetching email), turn on suspend on battery, and on charger, for GPS geoclue reduce accuracy and location scan interval frequency of GPS module etc…)
  2. Balanced (set power save options to on for devices not currently in use, dim screen in one minute, turn off in 2minutes, turn on suspend on battery, or if battery drops below 30%, turn off location services and daemons not in use, turn file syncing services off when not plugged in (like syncthing) etc…)
  3. Performance (set power save options off for all devices, turn off suspend)