From Openrepos:
https://openrepos.net/content/ade/system-monitor-fork
1 Like
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.
The ofonod-cpu-guzzling-problem is wellknown and monitored. Hopefully a fix for that behaviour will be adressed for the next update(s).
As workaround you can restart the service:
devel-su systemctl restart ofono
Works for me every time it occurs.
In my case it will be triggered once a cold-boot/restart session.
WLAN<->Mobile Data/Bluetooth-Connection/Disconnection seem to trigger that.
2 Likes
I don’t have any info to share on this and it’s not usually pre-announced I’m afraid, but any announcements will be made here in the forum of course (and following @dcaliste’s repository roundup is also always a good idea too).
Is there a special link for the “repository roundup”, I’m not sure, what you mean?
GitHub - dcaliste/sailfishos-digest This is the page where @dcaliste summarizes the latest source code updates on a biweekly/monthly basis
1 Like
Thanks for the link, I registered me for watching.
Did this pull request find its way in 4.4.0.72?
1 Like
Most likely not, looking at the detailed changelog. But it will in 4.5.
Power consumption on my 10 III remains very bad. Holding the 10 III in one hand and the XA2 Ultra in the other, with only Battery Buddy or AIDA64 running (in order to see current draw), I always get TWICE the power consumption of the XA2U on the 10 III. In such conditions the XA2U current draw fluctuates between some 50-80 mA, whereas on the 10 III its lower limit is 110-115 mAh.
BTW, what is your /mnt/vendor/persist/battery/battery_cycle_count saying? Mine has already reached 42 full cycles, which is really worrying.
After using both XA2 (Ultra) and X10II and X10III for long time, I do agree that X10III has sub-optimal battery life. The idle current is a bit high indeed, but I don’t have good ideas how to diagnose the power users beyond basic command line stuff…and that resolution, or worse, permission level, may not be enough. Ve may have to dig ourselfs into the AOSP territory here…
Or if we’re lucky, just some device configuration may be incorrect. The CPU governor/frequency issue was hidden in plain sight for months at least, there may be other values to fix, too.
1 Like
After many weeks of tests, I actually cannot see any perceptible difference when it comes to power consumption while using different governors (performance, schedutil, ondemand) or enabling 300 MHz as minumum frequency. Oddly, sometimes it actually turns to worse. And even if I see any improvement, it is actually so small that it’s not worth the hassle.
And it’s actually not a problem when the device is in sleep (when it goes as low as 35-40 mA if nothing wakes it up too often), the problem is when it is in use. Even light use, just holding it in hand with the display on is enough for it to eat 110-250 mA, with frequent spikes up to 500-600 or more. The XA2U with its huge and less power efficient display and 14 nm (i.e. probably also more power hungry) CPU draws 50-80 mA in such conditions.
1 Like
My understanding is that the display consumption in 10iii depends with the background colour brightness . Have you tried using a dark theme?