I’ve just rebooted the phone and governors of all cores were reset to defaults. And so were minfree values in /sys/module/lowmemorykiller/parameters/minfree.
Is it supposed to be like that? Guess I’ll need to create some script to re-set them to what I like after each reboot…
Did anyone tried doing echo 300000 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_min_freq , so cores can go down to 300MHz? It would make sense, to improve idle.
Also, I really suggest to use schedutil instead of ondemand , it is the most “clever” scheduler, most commonly used, the default for Sony on Android, and can be tuned, which we could try.
Done. Silver cores now indeed go down to 300 MHz. So far I haven’t noticed any negative consequences of doing so when using the phone. No noticeable slow downs, etc. I will check if it has any positive impact on battery life in idle/sleep and I’ll report soon.
Here are my SystemDataScope Logs of the last 30minutes. I was taking my dog out for a walk and used the phone stayed in my pocket most of the time. Only mobile data was on.
What do all those graphs tell us?
It shows that the phone switches between the set frequencies of 1248 an 2047Mhz depending on load. Most of the time the cores are in their C2 power save mode.
The interesting part is the cpu sleep graph. This is way too low. It should be around 90 or above when the phone is not used. The constant wake up of the cores is causing the battery drain.
Back in the days with my Sailfish Port for the Nexus5, it als suffered from battery drain. I compiled kernels with more power saving features, different CPU governors and fiddled with their settings. All this work only saved a few percent of battery life at the end of the day.
Finally we found the issue…the problem was that bluetooth, even if not in use constantly woke up the cpu and which lead to the battery drain.
So i think, all those fiddling around in the cpufreq folders will not solve the problem. Something is waking up the cpus too often, this could be the kernel or a part of SailfishOS.
Maybe installing powertop and doing a long time report could reveal which causes this issue.
I set the governors to ondemand, and set the min frequency to 300000 for all cores. I am getting readings of 6x 576000 and 2x 300000 even when ran from on device terminal, screen on as usual. With Bluetooth active and Nettiradio playing, the silver cores sometimes go up to 1Ghz. I don’t see much wrong here in my case…
And how is your power consumption?
In reviews the X10iii had a standby time of nearly 6 days, over 30h of calling time, 26h video playback and 15h of wifi web browsing…
For example: This bug causes many wakeups of the cpu:
Wow, I just found a typo in Sony’s source code. Turns out the minumum frequencies should be even higher! Because of a typo minfreq is not set for the gold cores, it defaults to those 300MHz, while it should be set to 652800.
A few lines above in that file there is minfreq set for the Silver cores too, where they raise it from the default to 576000. I really wonder why Sony does that.
Maybe they did this to prevent lag when waking up the device due to the cores not scaling up fast enough?
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?