Hi !
Maybe I am late … but:
Is that really normal that 8h only “ready-Time” (so not use, still lying on table, moderate 4G signal strengh, no messages, no calls, WIFI on OR off no big changes… ) takes me >25% battery capacity?
It’s not a new problem. It is since “years…”
I tried uninstalled apps, I hoped on eyery e-update, …
I do research on my own with
better battery state (62% deep sleep/37% awake Screen off = 62% CPU Deep sleep/32% @ 576Mhz)
Kernel Wakelock: RMNET_DFC (1h43min) qtr_0 (1h24min)
and
with Battery history (https://gitlab.e.foundation/groups/e/-/epics/318)
Full doze (Blue), a lot of kernel wakeup, (ca.30% only Kernel uptime) CPU running Prozesses on the graphic are often:
51 ipa
Abort: Pending Wakeup Sources: NETLINK NETLINK
Abort: Pending Wakeup Sources: qrtr_0
Abort: Last Wakeup Sources: eventpoll
Tables in the bottom: Kernel Wakesources:
|0|RMNET_DFC|11m32s541ms|691.80|1h42m14.587s|6128|
|1|qrtr_0|9m31s431ms|853.01|1h24m21.785s|7556|
|2|IPA_CLIENT_APPS_WAN_COAL_CONS|1m23s595ms|432.94|12m20.497s|3835|
|3|IPA_CLIENT_APPS_LAN_CONS|1m1s518ms|403.36|9m4.937s|3573|
|4|NETLINK|58s892ms|7243.67|8m41.672s|64165|
This “Abort:” thing is crazy for me. 3-7seconds CPU time for aborts every minute
I have now many files but I couldn’t find THE PROBLEM,
Any tricks and tips ?
Thank you very much !
Less. For the 3 February days I have 4MB total now. Always ON.
Bluetooth is mostly off.
I have compared 8h overnight with WIFI on/off and WIFI MasterStation on/off too.
Not a big difference. With WIFI connection maybe al little bit less.
LTE/4G mobile active with mostly “moderate” signal strengh.
With mobil data OFF it is really a difference. But why so much? There is no interval pulling.
mircoG Push is active and it is working
I don’t think much data is the problem. I set Signal and Threema sometime “No energy in background” and it changed nothing.
I thought google heartbeat was the problem, but total cpu-time is less.
Modern Mobil phone only <40h ready time by NO use without charging?
Really? Is that standard?
I could use the FP2 2-3 days with less use without charging.
The power consumption in heavily user case is good for me. Of course with much screen time, mobile data and GPS is one day OK.
But I think something is wrong in “deep sleep mode” …
I used to scroll through battery-historian profiles alot, I can have a look if you DM a link to a bugreport.zip.
Comparing drain rate is hard for different users of the same devices, but you could ask in the Fairphone forum if a user can record a 24h bugreport.zip on similar settings on stockrom and same radio settings - just for a ballpark figure to compare to.
Do you know that you can switch the mobile network off when wifi is on? There’s an option for this in the developer settings. This avoids a lot of senseless keep alive requests in the mobile network and saves energy. Normally /e/ lets the mobile network connection active while wifi is on.
You should have at least more than a day, typical two days (with flight mode over night).
the “Screen Off Discharge Rate (%/hr)” in your bugreport.zip with ~4%/hr is well above 1-1.5%/hr what I’d see as problematic during “human sleeps”.
You can rule out the apps, the drainrate originates from the modems behaviour or how the kernel interfaces with it. RMNET_DFC has 600 wakelocks per hour, as in 10 per minute. That thing doesn’t sleep.
Your kernel version and build string point at you using Android 12 - there are commits addressing rmnet dfc behaviour in the kernel used for the Android 13 based build that aren’t in the other branch. You could potentially benefit from an upgrade.
(rmnet is Qualcomms driver that lets your application processor (AP) part of the system talk to the modem)
There are reports in the fairphone forum of users unhappy with FP4 drain on Android 13 too, but then FP doesn’t ship Lineage kernels in their stockrom but what Qualcomm provides directly.
On my GS290 I had this issue. During updates a self installed APN may get lost. So after one of the updates my battery life was reduced and I had problems with mobile internet. Setting the APN again manually conform the instruction of the provider gave me back battery life.
Wow !
These kind of expert knowledge I was looking for! Thank you very much.
Just 1, 2 questions to completely understand:
If the standard android for FP4 now get these problem new with 13, it means there kernel in 12 has not this problem?
And the lineage version based on 12 has this problem and in 13 will not have anymore?
The other way double around ??
Also everybody with FP4 and /e/ should have this problem?
Yes it helps! Something like 5 percent over night/8h.
Or like “Screen Off Discharge Rate (%/hr)” from ~4 to 2.59 in tcecyk interesting point of view…
I will watch more nights but It feels like a different also over the day (if in Wifi area)
(I’d first give another kernel / potentially modem firmware a try before marking my answer as solution)
I browsed through kernel repos superficially. It seemed the 4.19.300+ kernel that is in use for A13 had rmnet dfc powersave code that the lineage maintainer reverted to apply the patch I linked - reasons aren’t stated, but I’d assume it works better for the overall power use . Fairphone stock will likely use what qualcomm implemented without any reverts. The A12 kernel you’re on (~4.19.159) won’t see improvements much. Also keep modem firmware upgrades in mind that can taint kernel comparisons. Anyway, test and measure.
I also have this battery drain problem with my FP4 (bought nearly 2 years ago from murena). Without any usuage battery life is about 32h. Also deinstalled all apps for testing. It is not easy to debug but it looks to me like it is related to LTE connection, so I will also try to switch mobile network off when Wifi is available. Thank you for the hint.
There was also a but report. It was closed but I still have this issue https://gitlab.e.foundation/e/backlog/-/issues/6852
not really, I just speculate from code and commits. But: you’re more likely to receive an improvement (or regression) when being more current on the kernel versions - and those are in the Android 13 build. You can flash an upgrade in-place, but there are risks. (I see you’re on 1.19.1-s-20240110372023-stable-FP4)
“dfc” inside rmnet probably stands for data flow control. There are commits from Qualcomm proper that try to improve power use but the Lineage maintainer seemingly preferred an older solution. It’s nowhere written what that decision is based on, you’ll have to test and measure (on same conditions).
What causes rmnet dfc to be active isn’t clear either, it can still originate from something Android queries for that keeps the talk to the modem alive. I have no explanation for what happens there systematically.
PS: also check if modem firmware is the most current. I guess they’re shipped with the flashing image but note down
I had an FP4 with e/OS for 2 years. Signal FOSS was a source of massive energy consumption for me, in the background 5-10% of the battery consumption went to this app alone. That’s why I got rid of Signal altogether.
In addition, the aforementioned settings in the developer options for throttling the wifi search and switching off the mobile network in the wifi greatly extended the runtime.
However, I always switched off my FP4 overnight. That way, I always managed 2 to 3 days on one battery charge.
Can’t remember that Signal has ever been so evil. When this happens, an app drains suddenly, it’s probably because of old cache data. Stop it, clear the cache of that app and restart it once. When my accu gets under 20% my Molly was never responsible for more than 3%.