-
Notifications
You must be signed in to change notification settings - Fork 7
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
battery life time #55
Comments
Its related to #27 Checked today and on 3.2.1.20 State right now:
I do wonder whether AOSP has longer suspend times with SIM card active and network used. |
not sure about suspend time, I guess you're referring to mobile network connection, in my case I had no sim card in, only wifi. |
WiFi is difficult to debug, usually its worse than on cellular data. Was stock with WIFI as well? Do you have some network accounts configured? Are they pulling with some time interval or set to 'always on'? Were the account settings the same for AOSP and SFOS? Realistically, we can work on getting parity without network. With network, you get too many variables and SFOS doesn't have push data support from Google servers, as Android has. Assuming that you used Android with Google apps installed |
Same conditions, Android had a basic google account no other installations, wifi was on, no sim card. On SFOS X I had a "mixed" upgrade to 3.2.1.20, wifi on, jolla account enabled, weather app, and telegrame which was not running. I had also installed collectd/RRDtool but I could not make it running, so it might had be running in background? I've removed them now. |
Do you have any email/calendar accounts enabled? Let's see if you have anomalies without WIFI or other connections. That's something which should be easy to check. As for collectd/rrdtool: you have to install https://openrepos.net/content/rinigus/systemdatascope and go through its config (see very short version and just follow that in its start screen). Without that config, it will not run by itself. I, obviously, use that for monitoring the system and that's why I could pull out the stats. Quite handy for such debugging |
no email/calendar accounts enabled yet, developer mode is on, but I will turn off ssh and lets see what we get. I am a bit suspicious of system monitoring tools overhead, we can start with an empty system, then I can add monitoring tools and find their overhead, then services. |
@pagism: sure, you could start without system monitoring. collectd is rather gentle usually, unless system config is wrong (as it was before I updated it to take into account differences in storage of XZ2 when compared to older models). My data is acquired with collectd running on each boot |
To get some stats, unless you want to use collectd, you could use the following: Recordings have to be done before and after the interval. These are:
The first one will give you number of suspend attempts: success and fail. The second one will tell you how much uptime (wall clock) and out of it time in suspend. We will need increase in suspend_time divided by increase in success. That way you can get average time of a single suspend. Try to find that out together with battery % drop per hour with and without WIFI. |
46% in 4hours (64-18), wifi off, no sim, it's too high by any means. Unless i did something horribly wrong.
Anyway, i need to be more systematic, it's charging now, i will use the stats you suggested tomorrow.
|
This is VERY bad. Sometimes, trackers go on after updates, but probably you don't have too many files over there. Check if you get suspended at all (mcetools) and which processes are high in top. Try to reboot as well. Without network, I have very low consumption, as described above. |
no chance to get stats overnight, battery depleted from 55% to ~0 in 4h 41m, no low battery sound notification either (unless i missed it) |
After some charging I managed to get some stats over a 2 hour period:
|
Changes between 2 and 3 look perfect:
So, we have 95% in suspend (dts/dtw) and average suspend time is 158 seconds. You maybe have hit some anomaly with trackers or such. Let's wait a bit and see if it will normalize now on low battery consumption without WIFI |
agrr, I turned on wifi, I can run the tests again tho, I have current charge ~80%, I will reboot the device, turn wifi off and keep monitoring every hour, how long do you want me to run the tests? |
no worries, use it as usual with WIFI and then check it for use with WIFI. During a night, let's switch off WIFI and test it in these conditions. |
I'll just chine in and say that everything seems to behave normal regarding battery life (wifi on, always up to date account). |
in my case the phone has an oled screen and it's not easy to identify whether battery consumption is from the screen itself or a rogue service, besides I would like to have wake up on proximity/double tap, and maybe enable notifications. however, I suspect higher battery consumption on xz3 due to its screen technology as current SFOS ambiences are not tuned for such screens. |
My previous SFOS phone had OLED as well (OnePlus X) and everything was fine with it. So, it shouldn't be an issue. I would more suspect 'rogue service' as a culprit. Let's see if you keep getting such high consumption without net first. Re double tap and proximity: should be possible to enable using mcetools (proximity), double tap would require something on kernel side. I presume it is there for XZ3, but I am not 100% sure - you will have to see if there are some settings on AOSP. However, let's get battery consumption under control first. |
Regarding double tap (you cant imagine how many times i double tapped the screen on the xperia 😄 :) i filed this > sonyxperiadev/bug_tracker#511 No answers yet. |
in stock Sony ROM the screen on idle was switched off, approaching a hand above the screen was turning a minimum set of notifications on screen and a double tap or a swipe was unlocking or something like that. I think such behaviour should be possible regardless screen technology, providing certain sensors are on? it's not urgent, maybe we need a new issue for this. |
@ApostolosB I still double tap on every black screen i have, bad habit from N9 days |
Let's keep double tap, wake on lift, to separate issue(s). Its something that we should add, but I am not sure its supported on AOSP. |
I will soon have idling stats for 7 hours, do we need more of those before moving to wifi tests? |
should be fine. So, what are the results? |
battery logs |
on idle test run for 7.5h battery level dropped from 80% to 66% |
During those 7 hours, was it just laying still and nobody using it? If all radios are off, I would expect it to behave better. Right now we have only 60% of suspend, that's rather little. If the phone is without radios (wifi, no sim, no nfc, no bt), I would be targeting something like 5% decrease during that time. And suspend should be > 90%, probably ~95%. So, I suggest to test during a night again. Maybe enable flight mode to be sure. |
exactly, no wifi, no sim, no nfc, no bt, so I think consumption is a bit high |
I hope I did the maths right, I used a quick awk script to parse log file |
I have not done anything else but using a rolling alarm every hour, from another device, to unlock screen, open the terminal app and invoke the log script. There is a strange result tho at 15:15. At that time. I left work and I was walking to car park. when I unlocked the screen the terminal app failed to start, (similar to the issue #51) on second time terminal started without issues. |
We are looking at That result at 15:15 is something we are targeting - about 95% of time is spent in suspended state. When I get to working on suspend issue, I will refresh my memory on how to track it. If you wish, you could read up on Android wakelocks, suspend and how to debug it. We will have to figure out what's causing it. |
I messed up dtw/dts, it had to be the otherway around, OK, I will have a look |
|
That's a good idea. Please also check out what does each column show specifically. I was reading on it a while ago and have forgotten most of it... |
here are the stats from last 12h+ with flight mode on:
It looks ok, I will continue testing with wifi on now. |
Excellent! I think we can conclude that in this mode all is OK now. |
wakeup_sources columns
|
wifi_on.zip
wakeup_sources data for those timestamps are also collected. |
I do not know how to analyse logs yet, but a rough estimation between flight vs wifi mode form battery level and prevent_suspend_time numbers shows a ratio of 5:1 agrr! I have done a mistake, wifi measures followed flight mode ones without reboot ;( that means counters on wakeup_sensor log files are started with an "offset" |
@pagism : I think those are expected values, more or less OK. So, it looks like that drain you experienced earlier was not reproduced in the last tests. Your values are also similar to what was reported by ljo at TMO, with WIFI. Its OK to have offset, we can correct for it. Thanks for collecting logs, those will be useful for later tuning, I think. |
there is nothing outstanding, compared to XA2 or stock rom consumption is higher, it's good to have the logs tho. I will also try to get another set of logs with wan only on, and wan+wifi on. |
Can toy provide a guess when comparing with stock how much larger is the consumption by SFOS? That way we will have a target... |
unfortunately I have not recorded that, I had the phone for a couple of days before flashing, just basic registration and wifi enabled. Overnight consumption was 3-5% if I remember correctly. |
No problem, I can ask at XDA. There is a hope for new SFOS users who may tell us what was battery consumption on stock/AOSP vs SFOS. |
I was thinking of that, if you put a note in flashing instructions for ppl to monitor and record consumption before flashing?
|
I think this is a relevant TJC issue to watch: xperia-10-battery-consumption/. Hopefully next update will bring some improvements. |
Probably. But those popup quite frequently, unfortunately. And its hard to debug those. Although, looks like they have similar short-sleep issues as we have. I'll keep an eye and start looking into our port |
Indeed it's hard, my feeling is that XZ3 consumption is above normal levels. I get the feeling that xperia 10 from those reports has a similar issue. At the same time XA2 has an excellent battery life (larger battery tho). XA2 is baseport-8 the other ones baseport-9. |
There is an answer in xperia-10-battery-consumption which claims the fingerprint as cause of increased battery consumption.
|
Fingerprint sensor probably makes sense to disable as we don't have it now #23 . Sailfish daemon is not there anyway. |
Disabled in sailfishos-sony-tama/droid-config-sony-tama-pie@bcd98ad . Will be a part of the next release |
Not systematically measured, I had overnight battery level drop from 89% to 60%, on stock OEM ROM the drop was below 5% as far as I remember. I will add new measurements over the next days.
The text was updated successfully, but these errors were encountered: