01-01-2025, 03:16 AM
(12-22-2024, 04:48 PM)dchang0 Wrote: Hi, everyone!
biketool got me thinking about this: is there a LINUX utility that can do the following:
a) log battery level over time (datalogger functionality for graphing)
b) log which processes or hardware modules (especially the modem) are consuming what power, in milliwatts
c) show power-related settings, especially those that might alter the power consumption
The primary objectives are:
1) to allow the PINE64 community to objectively compare their own experiences for the purpose of sharing settings, tips, tricks, and diagnoses to maximize battery life. There are too many variables to consider when comparing battery life, such as screen brightness, modem clock speed, settings, usage patterns, cell signal strength. With a datalogger we could see, for instance, that someone who complains about awful battery life might have a specific setting that's set wrong, or that someone else with awful battery life has a process that keeps waking the phone up, or that someone with fantastic battery life runs their screen brightness at the dimmest setting all the time, etc.
2) to improve LINUX distros' power optimization for the PinePhone and PinePhone Pro over time
PowerTOP can do b) and c), but I don't think it can do a) without having a serial-attached external datalogger.
It's probable that PINE64 has some kind of internal tool that profiles power/battery consumption as they design their hardware. If that exists and we can use it, that would be great.
If not, which 3rd party open-source LINUX tools are closest to fulfilling the objectives?
I'll search online, but if anyone knows already what tools to use, please share here. Thanks!
I would suspect much of the problem could be solved using the hardware acceleration hardware present in the chipset. Perhaps also utilizing the low rez mode on the screen when not needed. For example clapper video app seems to heat up the PPp about as much as idling with the screen active/unlocked, it is one of the only apps with the correct hardware acceleration compiled into the app itself rather than the OS. Almost everything else including the OS itself using CPU fallback. Most of the time all but one smaller CPU should be powered down. a study into how android and apple save power would be appropriate or even reviewing power savings including freezing unfocused apps unless specifically permitted would help. The Nokia N900/Maemo had a hardware abstraction layer, think of it as an API to abstract the hardware even though there was only one target device for the distro, this is ideal fr Pine librem and other android-first targets for the various mobile distros.
It is pretty clear that fixing power consumption has come a way with help from one dev especially, Megi(now retired); but is is also still by foar the most glaring problem with using the PP and PPp for any amount of time with the USB power unplugged. Less than 2 hours from 100% to battery empty shutdown with screen locked just listening to audiobook?!?! unacceptable for a real mobile device.