Probably, still a very weird decision in my opinion, to bring idle clocks 2x up just for that. If the frequency rampup was too slow they could have changed parameters of the governor, to make polling more frequent and other things.
Also it indeed was a bug that Gold cores were set to just 300MHz, they immediately merged my pull request to fix this bug: https://github.com/sonyxperiadev/device-sony-lena/pull/19
Edit: Wow, turns out the policy was incorrectly set, so values for Gold cores were set for last 2 Silver cores, and Gold cores were not configured at all! That explains Performance governor, not configured minumum frequencies, as well as maybe other things misconfigured too! https://github.com/sonyxperiadev/device-sony-lena/issues/20#issuecomment-1220478207
But even with these wrong settings all the reviews of the 10iii say that it has an excellent battery life?
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
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.
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âŠ
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âŠ
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.
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.
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?
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â.
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.
Are there any informations, when the next update will be delivered for 4.4.0.68?