Last active
March 31, 2019 19:28
-
-
Save crok/254026a405c82b0374617920e50eda1c to your computer and use it in GitHub Desktop.
SoT screen on time - why it is *not* a universal measurement for ROM / kernel battery management
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Android SoT is not a universal measurement of a ROM's or a kernel's battery management. | |
It strongly depends on way too many factors, like: | |
- display brightness | |
- mobile connectivity (signal strength / signal to noise ratio, network type, scanning / looking for better coverage..) | |
- wifi connectivity (signal strength / signal to noise ratio, network type, | |
number of neighboring devices (RF field busyness, etc..) | |
- frequency settings of SoC (CPU & GPU), governor behavor & "boosting" settings | |
(too much/too high? Possibly too much drainage.. | |
too less/too low? Possibly battery friendly but leading to too laggy UI behavior..) | |
- thermal throttling (reducing RIL capabilities will cause lower network speeds / reductions / restrictions | |
and thus the same amount of data traffic needs more time | |
and since the user is waiting but the UI & display is active the drainage will be higher) | |
- background apps and their activities (syncing data, userspace wakelocks, alarms in apps triggering activities | |
(refreshing data, etc..), lots of notifications via GMS, network location provider (NLP) wakelocks..) | |
- actual app usage pattern: 2D gaming // browsing the web // instant massaging // watching Youtube | |
(strongly depending on the video quality!) // 3D gaming are resulting / needing _way different_ CPU & GPU load | |
thus the same amount of "screen on time" made by different kind of activities are producing _way different_ drainage | |
and I hope this is trivial now for everyone ;) | |
If you want to measure a ROM's and/or kernel's battery management | |
then create / know your baseline of usage and then you can compare the ROM's and/or kernels, like: | |
- open the same video player and play the same video on different ROMs and/or kernels | |
- disable almost everything and leave the phone totally idle for hours and check the battery drainage | |
- be creative and create your own usage baseline.. | |
..and then you will know how good is the ROM and/or kernel in terms of battery management. | |
Please, whenever you publish a SoT value just let people know your usage pattern as well. | |
Without that info the SoT value itself is completely useless. I know this needs a lot of work.. | |
But many people are complaining out there and have no idea what's the background.. | |
PS - just an advise: if you think about it.. | |
finishing a task in less time and going back to idle is much better | |
than finish it in more time and go back to idle.. | |
It will results a snappier UI and more energy efficient - in my opinion. | |
Check the voltage/frequency table of your SoC in the kernel source | |
and try to find the most efficient frequencies, | |
use interactive CPU governor and set an appropriate freq. for hi-speed, | |
increase if necessary but go back to idle shortly when load reduces. | |
So set your CPU/GPU governors accordingly. | |
Have fun! |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment