Open pagism opened 3 years ago
is it reasonable to expect a newer release of the aosp blobs? the current release is from dec 2020
I suspect that no, looks like AOSP10 is sunset and development shifted to AOSP11. I will test whether legacy GPU driver will work and maybe check out if there is something else out there.
Legacy MSM driver was no go - it has not been updated in the kernel to newer interface and we cannot use it. One more option out of the window!
maybe we have to use aosp11 blobs, but that then will have to port SFOS... or wait until xperia 10 iii is ported.
let's be realistic, I can live with GPU glitches, the increased power consumption is just about bearable I would say? the rest of the stuff and apps are working ok, and the camera is ok-ish, at least it does not crash.
is there any expectation that we might get an improved driver in the near future?
I don't expect we will get newer AOSP10 driver, I am quite sure it is as good as it is. As there have been no updates for AOSP10, that's all we can expect. And probably now we need to realize that the current state of AOSP10 would not improve much and discuss the options. I will probably open a new thread at FSO to make visible for all users.
For reference, on AOSP9 based SFOS port
interesting, almost 4 times higher consumption in flight mode. but no difference with the sim enabled.
my usage has also on the wifi.
what tool do you use to collect the data?
Battery state could be different in different devices (my apollo vs my akari). So, as mentioned, I have to check with AOSP10 on Apollo as well.
I use collectd/SystemDataScope (obviously, as I ported collectd and wrote SDS), but probably something else can be used. Just measurements take time ...
thanks, it's important to use the same tools, i was a bit hesitant running collectd not knowning its overhead.
It should be minimal. But you could just record % on the paper as well :)
PS: collectd on SFOS by default makes a snapshot only once in few minutes
Observed the usage on Apollo, SFOS 4.0.1, Kernel 4.9, overnight. Had 4G network connected but not internet. Printed the energy as well. Turns out the average current consumption is around 26mA looking at the energy figures.
` 01:13 - 16 % | 297133 uAh | 3 hr 26 min | 20 mA 01:24 - 16 % | 292934 uAh | 3 hr 26 min | 21 mA 01:31 - 16 % | 289519 uAh | 3 hr 26 min | 22 mA 01:44 - 16 % | 284273 uAh | 3 hr 26 min | 20 mA 01:59 - 16 % | 277877 uAh | 3 hr 26 min | 23 mA 02:15 - 16 % | 271402 uAh | 3 hr 26 min | 22 mA
Energy consumption (1:13 to 2:15) = 25731 uAh
02:29 - 16 % | 265436 uAh | 3 hr 26 min | 21 mA 02:50 - 16 % | 256871 uAh | 3 hr 26 min | 20 mA 03:16 - 16 % | 245899 uAh | 3 hr 26 min | 21 mA
Energy consumption (2:15 to 3:16) = 25503 uAh
03:51 - 15 % | 231519 uAh | 3 hr 13 min | 22 mA 04:19 - 15 % | 217880 uAh | 3 hr 13 min | 21 mA
Energy consumption (3:16 to 4:19) = 28019 uAh
04:35 - 15 % | 210962 uAh | 3 hr 13 min | 21 mA 05:03 - 15 % | 199933 uAh | 3 hr 13 min | 180 mA
Energy consumption (4:19 to 5:3) = 17947 uAh
05:29 - 15 % | 188796 uAh | 3 hr 13 min | 21 mA 05:52 - 14 % | 179697 uAh | 3 hr 1 min | 22 mA 06:18 - 14 % | 169058 uAh | 3 hr 1 min | 22 mA
Energy consumption (5:3 to 6:18) = 30875 uAh
06:36 - 14 % | 161465 uAh | 3 hr 1 min | 22 mA 06:54 - 13 % | 153819 uAh | 2 hr 48 min | 21 mA 07:09 - 13 % | 147663 uAh | 2 hr 48 min | 22 mA
Energy consumption (6:18 to 7:9) = 21395 uAh `
I'll have to run the same test on my Apollo with AOSP10/aarch64 - then we can compare by battery %. Would have to see where I can get uAh data - any quick pointers?
@rinigus I was using the value recorded in "/sys/class/power_supply/battery/charge_counter"
Attaching the script that I use. Not very great, does the purpose, I believe. Records to a file "batterylog" in the same directory as the script. batterymon.zip
Thanks!
on xz3, aosp10, zgovernor enabled, using collectd, in flight mode, user in deep sleeping mode too:
battery 29uA on average, min 25uA over 4h period.
@pagism : what about battery %/h? feeling what it was before? as uA are probably picked up during resume moments
@rinigus observing the battery % graph consumption is 1%/h can we have a csv form of yhe graph too?
csv is maybe possible, but not trivial. easiest is to choose time window and then just calculate %/h from min/max values
Update after testing Apollo AOSP9 and AOSP10. This is an update from earlier message where I had to compare to Akari in one condition. Turned out that Akari and Apollo data are touch different, but difference is not major:
On AOSP9 based SFOS port
So, when used with SIM, the difference was not that massive. Here, AOSP10 was using zgovernor, not used in AOSP9
The figures are not that bad, there is massive difference in flight mode, but practically the use of that mode is minimal so not an real issue.
The result with SIM card in is more interesting, that's 30% higher, however in practice that impact might not be that significant if we take into account normal use of the phone with active connections and screen on where consumption is a lot higher and will have more impact on battery.
So let's try to use the device regularly, under normal conditions and revisit the issue.
Agreed, such testing is pretty much what we do these days
Tested without network, just SIM, on AOSP10 and without zgovernor - so no CPU on/off switching. Result was 1%/h on Apollo, so marginally better than with zgovernor. Will have to test on Akari and see if with normal usage zgovernor actually helps at all. But that is rather difficult to compare, though.
Update: now looking on the latest stats, I am getting 1.33-1.5%/h without zgovernor
Update 2: over 12 h, 1.17%/h
I guess more testing is needed with and without
I am going to test zgovernor changing GPU settings only. Got a phone responding in a bit choppy manner today and I suspect it is due to shifting most of its work to slow CPUs. Let's see whether it will hit the power consumption - I hope not much.
I do not have exact figures, power consumption compared to OEM Sony Android-10 feels considerably higher. It might be comparable to the previous aosp-9 port, and I know it will be difficult to trace it, besides it might originate down to aosp-10 layers.