But even with these wrong settings all the reviews of the 10iii say that it has an excellent battery life?
1 Like
Hard to know what the official ROM is using. Someone on official Android would have to root it and check those values. Maybe only the Open Source config is broken, Sony does it weird like that.
And no echo cancellation issues, wonder if it’s just aosp team being understaffed and not giving a damn or actual anticompetitive practice, aosp team starts work after official rom (according to post by rinigus on this forum) so would be really weird to have this regression and obvious ‘typos’ in the config
1 Like
Or if the next official OTA update will have “CPU power usage optimisation” in its changelog, then you will know why 
Yeah, they just copied values from some other device, and never adjusted number of cores or the frequency it supports. So weird, why don’t they take the config from the official release?! This is the one thing that should be directly copied, there are no secrets in that.
Or it was directly copied, and it was like that in the official version all this time. Sony’s software has a lot of random issues, including overheating, would explain things.
1 Like
Maybe Bluetooth plays some role in the 10 III power consumption, too, given the bug causing that SFOS phones remain discoverable after Bluetooth is (allegedly) switched off. One of those “evergreen” bugs, not fixed for years, also present on 10 III.
Even with all cores switched to ondemand and going as low as 300 MHz, there’s no noticeable improvement in power consumption in standby. With only the phone enabled and literally everything else turned off, completely unused, it still consumes 1% every 65 minutes. And with WiFi and mobile data on, this drops to 1% every 50-55 minutes. Changing governors and allowing lower frequencies doesn’t seem to have any serious effect, simply because, as you said, the CPUs wake up way to often, anyway.
Power consumption when idle is one thing, but hunger for power when in use is even worse. I’ve got identical OS setup on the 10 III and XA2 Ultra - same settings, mods, installed software, etc., and if I place them next to each other doing exactly the same, the XA2U eats 30-40% less, despite its large and less power efficient display and older less power efficient SoC…
My 10 III on standby eats 1% of battery every 50 minutes (which can be improved to 1% every 65 minutes if I disable literally everything but the phone). So this averages to ~ 1500 mAh per day, i.e. 3 days - HALF of what multiple reviews report for it. Calling time? Even worse. A phone conversation lasting 1 hour 22 minutes ate 20% of battery (and made the upper part of the display unpleasantly warm to touch my face with), which translates to some 7.5 hours of calling time. Losing 1% every 3-4 minutes during phone calls is quite typical for my 10 III.
So yes, those are pretty bad figures…
1 Like
So, this has happened a few times now, and happened again last night:
I plugged my phone (Xperia 10 III) to charger at 22.10 o’clock, and i unplugged it circa 30 minutes later before i went to bed. I woke up and set off the alarm at 6.30.
Normally the battery consume is approx 1% per hour when idling (mobile data on, WiFi off), but now it had went down 18% (so double the normal amount, and then some).
System Monitor showed the CPU sleep was disabled when connecting to charger, and it went back on when i woke up.
The charger is Sony’s USB-PD fast charger (XQZ-UC1), and i use Battery Buddy to limit the charge to 80%.
Any ideas?
Great work digging those out from the sources and getting them fixed upstream!
I fixed the policies in my X10III, and now the schedutil governor is set correctly on boot. I also set the minimum frequencies to 300000 as it seems to work fine in my device at least.
I got similar figures yesterday; 1% lasts for roughly 40-50 minutes (with ondemand governor). That’s with no processes acting up.
I have seen this, too. 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. If I use ondemand governor instead, the clocks remain low-ish. Using schedutil seems to be the recommened option, but it does seem to have its quirks…
1 Like
I started checking out powertop (installed separately). With ondemand I’m getting this frequency stats (with only Whisperfish running, Android AppSupport started but no opened apps) using SSH over USB to PC:
# CPU0..5
300 MHz 7,5%
576 MHz 3,6%
768 MHz 0,3%
1018 MHz 0,3%
1248 MHz 0,3%
1325 MHz 0,2%
1,52 GHz 0,4%
1,62 GHz 0,1%
1,71 GHz 3,6%
Idle 83,8%
# CPU6..7
300 MHz 0,1%
787 MHz 0,0%
979 MHz 0,0%
1037 MHz 0,0%
1248 MHz 0,0%
1402 MHz 0,0%
1,56 GHz 0,0%
1,77 GHz 0,0%
1,91 GHz 0,0%
2,08 GHz 0,0%
Idle 99,9%
With schedutil I’m getting these:
# CPU0..5
300 MHz 0,2%
576 MHz 0,0%
768 MHz 0,0%
1018 MHz 0,0%
1248 MHz 0,3%
1325 MHz 0,0%
1,52 GHz 0,0%
1,62 GHz 0,1%
1,71 GHz 5,1%
Idle 94,3%
# CPU6..7
300 MHz 0,0%
787 MHz 0,0%
979 MHz 0,0%
1037 MHz 0,0%
1248 MHz 0,0%
1402 MHz 0,0%
1,56 GHz 0,0%
1,77 GHz 0,0%
1,91 GHz 0,0%
2,08 GHz 0,0%
Idle 99,9%
So, it seems that schedutil makes the CPU ramp up to higher clocks for short tasks, too, which can be both energy efficient and fast. It seems to be working correctly. I’m also getting similar results with testing on-device without a charger connected – idle times are >90% and >99% most of the time with screen on and running PowerTOP in ToeTerm (with a miniscule font size).
I think schedutil gets a pass here! No need to switch to ondemand - the battery didn’t last any longer with it at least, but it didn’t do harm either.
2 Likes
So the cores were misconfigured only in AOSP, they were correctly configured in the stock Android. That is one of the many reasons why Android had better battery life, but it should get fixed for everyone in the next SFOS update.
2 Likes
I have seen this, too. What I think happens is that the
schedutilgovernor 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. If I useondemandgovernor instead, the clocks remain low-ish. Usingschedutilseems to be the recommened option, but it does seem to have its quirks…
It keeps happening almost every other night. Do you think there is a need for a separate bug report, or has this already been covered in an existing one?
where’d you get that?
Until these reach a proper release, maybe zgovernor can be updated to use the updated values?
1 Like
With collectd + systemdatascpre, you would even be able to gather long-time readings of all kinds of valuea and graph them.
Maybe someone with another Sailfish device, exvept the 10iii could post his Systemdatascope cpu sleep graph?
As discussed above, it’s possible that things will be improved by the recent fix that @JacekJagosz contributed, so it would be good to know whether that’s noticeable after the next release.
In the meantime, we now have this reported internally and I’ve tagged the topic as “tracked”.
3 Likes
After many weeks of using ondemand governor and 300 MHz minimum frequency for all cores, a few days ago I switched back to the default settings, i.e. schedutil for cores 0-6 and performance for 6-7. I did so because I’ve had problems with the fingerprint sensor which became unresposive (multiple touches or placing a finger over it and waiting a few seconds were very often needed for it to wake up and react).
Back on default config I get the same, if not even slightly better (!) battery life, and all the issues with “sleepy” fingerprint sensor seem to be gone. Last two nights, with everything but the cellular radio off (and battery saving mode on), the device was consuming 1% per 80 minutes, compared to 1% per 65 minutes when all cores were switched to ondemand and minumum frequency was lowered to 300 MHz.
So this is really strange…
I will keep the device a few more days on its default settings to further confirm the above. Then I will test different things SEPARATELY (e.g. only lower the min freq to 300 MHz, or only change the Gold cores’ governor) to see what has such a negative impact on the touch sensor’s responsiveness.
Anyway, all this isn’t really worth the hassle. Changes in battery life are negligible, anyway, if not actually to worse. With or without those modifications, the 10 III remains an energy hog, eating almost twice more energy than the XA2 Ultra. It takes looking somewhere else for power consumption improvements. Eating 1% of battery every 3-4 minutes during phone calls or every 10-15 minutes during simple usage like web browsing is many times worse than power consumption under stock Android, confirmed by many reviews available on the web. This is where serious improvements are needed.
3 Likes
Are there any informations, when the next update will be delivered for 4.4.0.68?
1 Like
The latest incident with high battery drainige was now when also mobile data started behaving badly (no 4G, no internet).
I got about 400-500mA constant drainige and I saw with CSD tool that instance /usr/sbin/ofonod was using 100,2%. It sounds a bit weird to my ears.
When I got mobile data working again with multitude of resets/flymodes, then ofonod wasn’t anymore at all on the list of power consumers. Drainige dropped to about 100mA.