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.