High battery drainage Xperia 10 III

As far as I followed this issue since summer 2022 I draw my personal conclusion:

  • I don’t expect that this issue will be solved for the Xperia 10 III in the next months (I didn’t see any hint from Jolla).
  • Using a newer AOSP for the phone it pretty much work (I read somewhere from attah), so rather unlikely to happen.
  • I can use my Xperia 10 III as a daily driver, and I’m quite happy with it (even if I have to charge nearly daily).

But: I hope that the following official supported model (after the Xperia 10 III) has a better energy efficiency. Before I’ll buy the next generation Xperia I’ll read, how battery drainage is measured by users here in the forum ;-).

A quick update to my issue with this:

I went through, let’s just say, a huge log (suggestion by @poetaster). Long story short, found a bunch of CPU consuming processes (nothing to worry about). After that i checked once more my Nextcloud account settings, and to my surprise i had enabled sync schedule every 15 minutes. I adjusted it and even turned it off, but still those graphs were going haywire. I ended up deleting the account, and things went back to normal. I created the account again, and even tried enabling the sync schedule back again, and the problem i described earlier was gone. I don’t know what happened, but if i dare to say, now i’m a happy camper… i mean, sailor again.

Look’s like 4.5 is a pretty nifty update after all. I’m looking forward to see new features, like Camera2 API.

And what comes to the original topic: yes, battery life could be better (comparing to what i saw on Android), but it is still good enough (better than what i had with XA2), so i’m not really disappointed.

1 Like

Unfortunately that’s a hope, there is not guarantee that the next xperia device AOSP will not have similar of other new issues.

These seem to control some kind of Active/Inactive state of cores which must be something different than the Online/Offline state, because the cores are still shown as Online, e.g. in /sys/devices/system/cpu/offline and /sys/devices/system/cpu/online, or in the /sys/devices/system/cpu/cpu0/core_ctl/global_state file. Please note how in e.g. /sys/devices/system/cpu/cpu0/core_ctl/global_state file where details of all cores are listed, there is a clear distinction between “Active cores” and “Online” states.

In order to switch a core to offline mode, one needs to:

echo 0 > /sys/devices/system/cpu/cpuX/online

and only then it gets really offline and is listed as such in /sys/devices/system/cpu/offline, /sys/devices/system/cpu/online, /sys/devices/system/cpu/cpuX/core_ctl/global_state, etc.

I’ve switched all cores but 0-1 to offline and there’s a noticeable performance drop, but I haven’t yet tested how it affects power consumption.

Also, while I can switch a core between online and offline manually by writing 0 or 1 to the corresponding file, I cannot find any mechanism to do it automatically based on load (similar to the one you posted that switches cores between active/inactive).

Well, I’ll need to test it if it gives any power saving. If it does, at least it will be easy to handle it programmatically, e.g. patch the Battery saving mode to additionally switch cores to offline.

I think the cores are not completly offline, but put in their deepest sleep mode. Active_cpus in core_ctl shows how many cores are active. I think core_ctl is not present on the XA2. Maybe the old offline/online method is deprecated on newer Qualcomm cpus…but i don’t know. The thing i know, that all this cpu fiddling does not noticeable increase the battery life. It would do if the drain was like it was on the XA2. There is some other thing totally wrong.

Yes, my experiences with this are similar. But since I haven’t yet tested that online/offline switching (which is what the XA2U uses), I’ll give it a try and see if it makes any difference (power-wise, because impact on performance is clearly noticeable).

Indeed. If this online/offline thing doesn’t make any difference (and I suspect that it doesn’t) then there’s something else than any CPU-related things eating that much energy, and we won’t be able to do anything about it.

1 Like

Hi wetab73, I tried to use your command to set my cores cpu2, cp3, …, cpu7 in their sleep mode.
In that night: 1% battery lasted for 1h 6 min

Reboot phone, without this commands:
This night: 1% battery lasted for 48 min

I’d like to try the following idea:
When this display is off, the 6 cores (perhaps 7) should be set in sleep mode with the commands mentioned above, for example by “Situations”. When display is activated, the cores should be enabled again.
Could someone help me, how to get this “devel-su” commands done in Situations?

For my personal purpose, the phone has not much to do with deactivated display:

  • check for mails or Signal-notifications
  • hear music over BT

I experimented some with the offline cores, and my findings are similar: there’s only a small difference in power consumption. It looks like the mysterious power consumer is not the core count either…

Have you some experience using Situations with devel-su commands?

No, sorry, but afaik devel-su always requires the password. You could install sudo instead and put the exact commands to /etc/sudoers, but that’s something to deal with care. I don’t know how e.g. Sailfish OS updates react to sudo, for example. Has someone tried?

Edit: Well, sudo is available from Jolla repos directly, so it should be “safe” to try at least…

ok, I open the file like this:
[root@Xperia10III defaultuser]# visudo /etc/sudoers

and try to add the line:
echo 0 > /sys/devices/system/cpu/cpu2/online

Try to write, I get the error:

[root@Xperia10III Downloads]# visudo /etc/sudoers
/etc/sudoers:1:8: syntax error
echo 0 > /sys/devices/system/cpu/cpu2/online
       ^

How could I fit this?

I would put the commands you ececute in a bash script and put this script in the sudoers file, like this:

ALL ALL = (root) NOPASSWD: /home/nemo/name-of-script

1 Like

Yesterday I had a very long phone conversation. It lasted 3 hours and consumed 26% of battery. So the actual talk time is less than 12 hours, which is just pathetic. 10 III tests / reviews with stock Android rate it at 31 hours of talk time, i.e. whopping 3 times more. What does it do under SFOS / AOSP that during calls it eats 3x more energy is beyond me. And where does that excess energy go? Heat? Increased SAR into our heads? It has to go somewhere.

2 Likes

Not looking good at all. At least you didn’t get disconnection at randoms of mobile signal like me on i4133 on 4.5

Hi, yesterday I restarted fingerprint-sensor (over Sailfish utility). The next morning the cpu-usage was better than the day before.
Exists a similar command to deactivate the fingerprint-senor?
I’d try the influence of it over night concerning battery drainage.

You could stop the sailfish-fpd service or try this method:

My Sony Xperia 10 III sometimes consumes around 10-15% during night - doing nothing (?). I charge it basically every day (stock SFOS, no Android support, no apps constantly running, no BT, rarely WLAN, etc.). Actually, my Jolla 1 has better battery consumption and lasts longer :smiley:

1 Like

Thanks. I tried
[root@Xperia10III defaultuser]# systemctl stop sailfish-fpd
It had no influence on battery drainage.

Maybe it could be related to this (one of my earlier posts from this thread):

A bit later @direc85 suggested:
“What I think happens is that the schedutil governor is aware (or its calculations are affected by) the connected charger, and it simply cranks the clocks to max. I think that’s a bug, because the clocks stay maxed out even when the display is off.”

Do you have SysMon or SystemDataScope to see what’s going on?

It hasn’t - as long as it works normally. But from time to time it gets kind of ‘stuck’ and in such state it consumes CPU time.

Normally, it uses around 1 second of CPU time when it gets touched and attempts to recognize the fingerprint, and after that it doesn’t use any CPU time until it is touched again. One can check it in e.g. Crest: open details of the /vendor/bin/hw/android.hardware.biometrics.fingerprint@2.1-service.sony process, check the CPU time consumed so far, then turn off the display and wake it up by touching the fingerprint sensor. Then re-open the page with details of that process - the CPU time will increase by 1 second.

In such case, even after several days the CPU time consumed by that process is just seconds - simply 1 second per each fingerprint recognition.

But quite often it gets ‘stuck’ - it doesn’t deactivate itself and continues using CPU time. In such state it not only eats power but it also stops reacting to touches.

See the screenshot below (from Crest) - it is after the sensor got stuck and ate over 40 minutes of CPU time. Normally, for that process to use 40 minutes of CPU time it would take 1 second * 60 * 40 = 2400 fingerprint scans, i.e. weeks of uptime. But when it gets stuck, it eats this much CPU time within minutes.

Resetting the sailfish-fpd service doesn’t seem to have any impact on this /vendor/bin/hw/android.hardware.biometrics.fingerprint@2.1-service.sony process.

2 Likes