Standby Battery high drain on Xperia 10 III

[crun]

This is only for standby current
I am splitting this off from the original topic of High Battery Drain X10iii because

1. It is a reproducible, testable and specific issue. The standby current is not dependent on signal strength, base stations etc. It should be much easier to test , find a fix, and prove it has been fixed.
2. Until it is fixed, other power drain issues are masked by it.
3. Jolla has not acknowledged standby drain as an issue, and may not have it marked as a bug requiring a fix.
4. The original thread is muddied by many issues. This is only for standby current

REPRODUCIBILITY: 100%
OS VERSION: All up to 4.5.0.19
HARDWARE: X10iii
UI LANGUAGE:
REGRESSION: no

DESCRIPTION:

The X10iii has a standby current drain of 0.7-0.8% /hour, when in flight mode.
(This is greater than the extra power to run the cell+wifi+bt radios, and is the biggest contributor to the X10iii short battery life)

The X10iii Android has ~0.2%/hr in flight mode
The XA2 0.25%/hr
X10iii SFOS with wifi and cell, at 0.75%/hr i.e. ~ the same as with them off.
X10iii Android with wifi and cell 0.55%/hr or lower. (I am in a weak and very variable signal area)

The phones were also tested turned off. No change in battery % over 24hrs

PRECONDITIONS:

STEPS TO REPRODUCE:

My methodology is to charge the phone to 80% (happy with the end-charge setting. Yay!)
Then I set the phone up how I want and leave it unused in a standard place for some hours e.g. overnight.
I then take (InitialBatt%-FinalBatt%)/NumHours = %/hr
These numbers have remained fairly consistent at different battery levels, so I consider the battery gauge readings to be roughly valid.

The basic condition to be fixed is: just restarted, flight mode, no apps running, no Android runtime, no location, NFC off.
Initially this was happening before android runtime was installed. Having a skype running has no significant effect on the drain.
Others have disabled the fingerprint sensor with no reported effect.

132
189
213

EXPECTED RESULT:

Same or better drain than Android.
It should be drawing nothing except the ram retention current, and the fingerprint sensor current. (because cron type processes should have set up the hardware RTC, and not be requiring cpu operation)
Also it should be possible to disable the fingerprint sensor. When a phone is put in a pack, things will brush/bounce against the sensor as you walk, and might result in hundreds of activations/hr

ACTUAL RESULT:

0.75%/hr

MODIFICATIONS:

none

ADDITIONAL INFORMATION:

It has been suggested that this would be from Sony AOSP, but so far this is untested

[Vince]

Is it allowed to bump bugs? Why does Jolla just not give a single fuck about this problem?

[pherjung]

Because they are a small team and don’t have the time to set the priority to everything.

Feel free to contribute to the project.

[Vince]

You sound like the type of guy who is perfectly fine with paying for a tablet and receiving nothing.

[crun]

It would be useful to make some measurements the same way I did, and confirm you have the same issue, and what your numbers are.

Another useful thing to do would be to test the Sony AOSP builds and confirm if this issue originates with AOSP.

[ua0056]

Can confirm that modifying processor options (scheduler/frequency), or altogether disabling CPU stand-by has no noticeable effect on power dissipation.

Remarkably, stopping the droid-hal-init.service, which kills all those suspiciously dodgy /vendor/bin/hw/android.hardware… processes, results in a significant increase of battery drain (by about 2x). This disables a bunch of things, such as the display, so have a care. Also, it does not appear the service can be restarted easily, so the whole device must be. Surely because systemd is so wonderful.

Any idea whether there are /sys (or /proc) files controlling the power state of the various peripherals? Considering the average current draw during stand-by (display off) is about 30 mA, while it should presumably be less than 5, something is probably not being powered down. Such as a radio.

[nephros]

I just wanted to add a link to my observations here:
Logind and udev are dancing in the night:

Process systemd-logind constant 3-7%CPU usage, scanning camera and audio devices

REPRODUCIBILITY (% or how often): 80% BUILD ID = OS VERSION (Settings > About product): 4.2.0.21 (Verla) HARDWARE (XA2, X10, X10 II, …): X10DS UI LANGUAGE: en REGRESSION: (compared to previous public release: Yes, No, ?): ? DESCRIPTION: Several monitoring tools (ps, dstat, top, htop, collectd/systemdatascope…) show systemd-logind eating resources all the time. Not much, but constantly. Here’s what collectd/systemdatascope produce: [Screenshot_20211111_001_e] UPDATE1: It appears the p…

Not specific to the 10iii but this phenomenon appears when the display is off and may contribute to the OP issue.

[vige]

Added to internal tracker, even though I somewhat doubt adding yet another bug really has a positive impact.

[robang74]

@ua0056

Can confirm that modifying processor options (scheduler/frequency), or altogether disabling CPU stand-by has no noticeable effect on power dissipation.

I believe you about what you wrote (observations), but not about the conclusion.

Do a confutation test

Execute code in order to force all the CPUs running at their maximum speed for some time, e.g. 10 or 15 minutes. What are our expectations about this experiment?

• All the CPU fully work-loaded do NOT have a significant impact on the battery’s lifespan.
• The contrary, they are able to drain a lot of energy from the battery.

It is reasonable to think about the second, but trying to make all the CPUs sleep does not bring the results expected. The keyword is trying. In fact, with the System Monitor my observations report that there are a HUGE number of CPU sleeping failures.

HINT

On this page, you can find a scripts suite that can create a tarball sysdebug containing stress-ng a command-line tool that can put your smartphone’s CPUs under full work-load.

WARNING

Furthermore, I reduced the test time to 10 or 15 minutes because, in the unlucky scenario in which the CPUs’ thermal throttle is broken, down, or whatever but not correctly functioning, you seriously risk literally cooking your smartphone. Therefore, the first time you play with it, pay close attention to the CPUs’ temperature, and System Monitor may not help but trick you because monitoring my Xperia 10 II, it reports 36°C all the time.

They are trying to sleep, but they get awakened almost immediately, and this clogs the system logfile, and guess what? The syslog is writing on the internal flash, and each write awakens a CPU, which creates a failure syslog message that should be written on the internal flash.

Why does this happen?

My hypothesis is that the SG/DMA is not activated and the filesystem caching is very limited or absent at all. Which makes sense for a mobile device that can safely - even if brutally switched off by the pressure of hardware keys driven by the user - keep data saved on the internal flash in real-time like sync filesystem option or near similar in effect.

How to easily confute my hypothesis?

Move the syslog to a tmpfs, with the precaution to kill the syslog daemon - if it still exist in user-space and it is the same that convey the kernel error/warning messages - because replacing it with a symlink pointing to /tmp will not close the file descriptor that syslog daemon is using. However, these information about syslog and syslog daemon have been collected a long time ago and possibly they are obsolete by now or specifically for SFOS.

@ua0056

Considering the average current draw during stand-by (display off) is about 30 mA, while it should presumably be less than 5, something is probably not being powered down. Such as a radio.

At 230mA, my Xperia 10 II can last 12h. Doing a linear proportion at 5mA it would last 550h which is definitely too much even for a standby but not hibernated system. Using the same linear proportion, at 30mA it would last 92h and this sounds reasonable instead. At least for me.

@ua0056

This disables a bunch of things, such as the display, so have a care.

A total black screen (aka all the pixels at #000000 color) consumes less energy than a white screen ONLY if the display is based on OLED technology or better. IPS displays do not have the feature of powering down the simple pixels or a relatively small matrix of them.

Therefore, there is quite a difference between disabling a hardware sub-system and cutting its link to the energy source, the battery. For example, GPS usually receives energy even when it is not used and disabled, but with gpstoggle we can cut it.

[miau]

Once again, nothing new, just read the thread aboit the 10iii power consumption.
Stop talking about things you don’t know a shit about. No one cares.

[Blumenkraft]

These posts are deliberately time and nerve consuming. Don’t try to argue with him at all because that’s just feeding the troll.

As a user of this forum, please consider flagging these kind of posts as spam. Thank you.

[beta4]

When my XA2 developed a GPS fix issue I took the opportunity to get a new device, and bought the 10 III. Recently flashed it, so far everything works, but the battery drain felt higher than normal. I don’t use my phone much, so I really enjoyed the XA2 long battery life, stretching several days before needing a recharge.

Did a comparison test with my XA2. Left both unused for 22 hours with a sim inserted but in airplane mode, no wifi, no bluetooth, no nfc, fingerprint sensor not configured.
Over this time the XA2 discharged 3%, the 10 III went down 13%.

From there I calculated the average current draw looking online for the phones battery capacity:

• 10iii 4500mAh * 0.13 / 22h = 26.6mA
• XA2 3300mAh * 0.03 / 22h = 4.5mA

A while ago I had a similar problem with my laptop idle power consumption, it turned out to be an unconfigured peripheral, in that case the GPU that was not used (I was using the internal GPU) but was drawing ~10W while doing nothing. I fixed it with a one line script that at every boot just did

echo ‘auto’ > ‘/sys/bus/pci/devices/0000:01:00.0/power/control’

I wonder if the problem is similar, since we’re looking for a ~20mA additional current draw it could be any peripheral, from bluetooth to the FM radio, that is either left unconfigured or not put in power save when needed that is causing this high power consumption.

Unfortunately, here is where my competence ends. I know smartphones peripherals aren’t connected via pcie, and I guess there isn’t an uniform interface to their power management, but maybe somebody can point me to how to poke the drivers to experiment with peripheral power saving.

Of course, if jolla would release an update that fixes the issue that would be even better

In the meantime I am undecided whether to temporarily keep using my XA2 (whose GPS fix issue I resolved by cleaning and gluing back the top cover) or live with the higher battery drain of my new 10 III.

[crun]

Good work doing some measurements.
There are several things we do know.
Factory Sony Android has much lower drain.
Turning off modules like BT, NFC etc, doesn’t help.
Apart from the flight mode standby drain, the operating standby drain of the radios does not seem to be excessive.
No one has reported on the Sony AOSP android port. i.e. Is the problem from SFOS or from the underlying AOSP it uses.
(I was going to test it but Vige’s comment made me think I am wasting my time, so I stopped)
BTW the same applies to the well known poor GPS acquisition issue, that affects the 10 III and the XA2, but does not affect Android. Is it an SFOS vs Android issue or an AOSP vs Android issue?

[voidanix]

@crun

No one has reported on the Sony AOSP android port. i.e. Is the problem from SFOS or from the underlying AOSP it uses.

Just because it is not present on SODP’s bug tracker does not mean that the problem does not exist.

If you are good enough at this, you should be able to identify if the issue is userspace or kernel related and what it might be.

For the brave ones I recommend to flash AOSP 11 and check for the same issues to rule out any variables.

[robang74]

@beta4

From there I calculated the average current draw looking online for the phones battery capacity:

• 10iii 4500mAh * 0.13 / 22h = 26.6mA
• XA2 3300mAh * 0.03 / 22h = 4.5mA

A while ago I had a similar problem with my laptop idle power consumption, it turned out to be an unconfigured peripheral, in that case the GPU that was not used (I was using the internal GPU) but was drawing ~10W while doing nothing. I fixed it with a one line script that at every boot just did

echo ‘auto’ > ‘/sys/bus/pci/devices/0000:01:00.0/power/control’

There are about 1.400 peripherals that uses power control

redfishos:~ # find /sys -name control | grep power/control | wc -l
1408

redfishos:~ # grep -v -e auto $(find /sys -name control | grep power/control)
/sys/devices/platform/soc/4c90000.qcom,qup_uart/power/control:on

redfishos:~ # list=$(find /sys/devices/ -name control | grep power/control)
redfishos:~ # for i in $(grep -v auto $list | cut -d: -f1); do echo auto >$i; done

and it takes less than 7 seconds to find and fix allo of them but did not change anything.

[Gunnson]

About two months ago I switched from XA2 to 10 III. Beside all other benefits, I was amazed by the wonderful battery life. I could easily make it through two days. But then from one day to another the phone always discharged within hours. You could watch the SOC going down. Deactivating functions, uninstalling Apps, restarting after charging, reducing brightness, etc. didn’t help at all. In CSD tools I saw that the discharge current was always between 600mA and 1A. The exchange process sailfish-eas was listed with 101.3% (whatever that indication means). Disabling and even deleting my outlook account didn’t help but ending the process with pkill sailfish-eas did the job. The current consumption went immediately down to 100-200mA. After a restart the issue directly returned. So in the end I simply un- and reinstalled the Exchange App from Jolla store and repeated the account set-up. That was three days ago. Battery live is still good, all exchange functions are working and sailfish-eas is not even listed within the high consumers…happy again