Power consumption while idling #154

pagism · 2021-06-29T16:30:25Z

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.

rinigus · 2021-06-29T17:32:02Z

I have a feeling it is higher than SFOS based on AOSP9, but I am not sure yet. Will look into whether I can make suspend stay for longer.

pagism · 2021-06-29T18:17:17Z

thanks, it's not a top priority issue, rather than a optisatiom one. i do not know how much is an aosp-10 issue or sfos tunning.

rinigus · 2021-06-29T18:27:46Z

It may run hand-in-hand with framerates being slow. Maybe I need to look into CPU/GPU governors and see if all can be improved.

pagism · 2021-06-29T19:02:00Z

cat /proc/cpuinfo is almost identical to xa2, the only difference is the features lines that has more capabilities. i found tgat surprising as the two devices have different cpus

rinigus · 2021-06-29T20:18:01Z

Looks like suspend stats are OK. At least offline/wlan only are very decent. With SIM card working, most of the wakeups coming from qrtr_0 (/d/wakeup_sources).

Will continue looking.

pagism · 2021-06-29T20:51:07Z

i can run some tests, what's the best way ti monitor activity? e.g. airplane mide, wifi only, cellular

rinigus · 2021-06-30T06:21:48Z

No, not yet. let me check few things first

pagism · 2021-06-30T07:32:28Z

One observation, it seems that consumption while idling sometimes is really low and some other times it's draining fast.

pagism · 2021-07-01T14:18:46Z

available governors and frequencies for cpubw using ssh connection

[defaultuser@XperiaXZ3 soc:qcom,cpubw]$ cat governor 
bw_hwmon

[defaultuser@XperiaXZ3 soc:qcom,cpubw]$ cat cur_freq 
8132

[defaultuser@XperiaXZ3 soc:qcom,cpubw]$ cat available_frequencies 
2288 4577 6500 8132 9155 12298 14236

[defaultuser@XperiaXZ3 soc:qcom,cpubw]$ cat available_governors 
compute mem_latency bw_hwmon vidc-ar50-llcc vidc-ar50-ddr msm-vidc-llcc msm-vidc-ddr gpubw_mon bw_vbif msm-adreno-tz userspace powersave performance simple_ondemand

rinigus · 2021-07-01T16:11:02Z

Yes, already checked most of them. Not all of them work for us, some lead to crash even. cpufreq governors are the one that is used to setup CPU frequencies and initialized in /vendor/etc/init/init.tama.pwr.rc . Although, some of the init sequence fails in SFOS and AOSP10 as well (error messages in dmasg).

Will have to check it out:

Jul 01 10:05:42 XperiaXZ2Compact droid-hal-init: Command 'write /sys/devices/system/cpu/cpu0/cpufreq/interactive/use_migration_notif 1' action=sys.boot_completed=1 (/vendor/etc/init/init.tama.pwr.rc:66) took 0ms and failed: Unable to write to file '/sys/devices/system/cpu/cpu0/cpufreq/interactive/use_migration_notif': open() failed: Permission denied
Jul 01 10:05:42 XperiaXZ2Compact droid-hal-init: Command 'write /sys/devices/system/cpu/cpu0/cpufreq/interactive/target_loads 83 1766400:95' action=sys.boot_completed=1 (/vendor/etc/init/init.tama.pwr.rc:72) took 0ms and failed: Unable to write to file '/sys/devices/system/cpu/cpu0/cpufreq/interactive/target_loads': Unable to write file contents: Invalid argument
Jul 01 10:05:42 XperiaXZ2Compact droid-hal-init: Command 'write /sys/devices/system/cpu/cpu0/cpufreq/interactive/max_freq_hysteresis 79000' action=sys.boot_completed=1 (/vendor/etc/init/init.tama.pwr.rc:74) took 0ms and failed: Unable to write to file '/sys/devices/system/cpu/cpu0/cpufreq/interactive/max_freq_hysteresis': open() failed: Permission denied
Jul 01 10:05:42 XperiaXZ2Compact droid-hal-init: Command 'write /sys/devices/system/cpu/cpu0/cpufreq/interactive/ignore_hispeed_on_notif 1' action=sys.boot_completed=1 (/vendor/etc/init/init.tama.pwr.rc:76) took 0ms and failed: Unable to write to file '/sys/devices/system/cpu/cpu0/cpufreq/interactive/ignore_hispeed_on_notif': open() failed: Permission denied
Jul 01 10:05:42 XperiaXZ2Compact droid-hal-init: Command 'write /sys/devices/system/cpu/cpu4/cpufreq/interactive/use_migration_notif 1' action=sys.boot_completed=1 (/vendor/etc/init/init.tama.pwr.rc:81) took 0ms and failed: Unable to write to file '/sys/devices/system/cpu/cpu4/cpufreq/interactive/use_migration_notif': open() failed: Permission denied
Jul 01 10:05:42 XperiaXZ2Compact droid-hal-init: Command 'write /sys/devices/system/cpu/cpu4/cpufreq/interactive/target_loads 83 1920000:90 2092800:95' action=sys.boot_completed=1 (/vendor/etc/init/init.tama.pwr.rc:87) took 0ms and failed: Unable to write to file '/sys/devices/system/cpu/cpu4/cpufreq/interactive/target_loads': Unable to write file contents: Invalid argument
Jul 01 10:05:42 XperiaXZ2Compact droid-hal-init: Command 'write /sys/devices/system/cpu/cpu4/cpufreq/interactive/max_freq_hysteresis 79000' action=sys.boot_completed=1 (/vendor/etc/init/init.tama.pwr.rc:89) took 0ms and failed: Unable to write to file '/sys/devices/system/cpu/cpu4/cpufreq/interactive/max_freq_hysteresis': open() failed: Permission denied
Jul 01 10:05:42 XperiaXZ2Compact droid-hal-init: Command 'write /sys/devices/system/cpu/cpu4/cpufreq/interactive/ignore_hispeed_on_notif 1' action=sys.boot_completed=1 (/vendor/etc/init/init.tama.pwr.rc:91) took 0ms and failed: Unable to write to file '/sys/devices/system/cpu/cpu4/cpufreq/interactive/ignore_hispeed_on_notif': open() failed: Permission denied

Right now working on idea of switching off power-hungry CPUs and keeping only low-power CPUs available while screen is off.

pagism · 2021-07-01T18:16:59Z

i thought checking the settings in the oem android, but required root access which i do not have. how android can achieve those power savings?

rinigus · 2021-07-01T19:19:50Z

Re Android power savings: I don't know, unfortunately.

rinigus · 2021-07-01T19:57:38Z

Out of the failures above, only target_load exists and fails. The rest of the API is missing, maybe updated with 4.14 kernel.

pagism · 2021-07-01T21:24:51Z

i csm flash it bavk to android if we can get tge info from there but i have the feeling the oem 'aosp' is very different to what we have?

rinigus · 2021-07-02T05:57:27Z

stock != aosp android. as far as I know, even kernel versions are different.

pagism · 2021-07-02T08:06:28Z

I know, for XZ3 with OEM Android 10, version 52.1.A.3.137 and kernel version 4.9.186-perf+

rinigus · 2021-07-02T17:16:23Z

While I am looking into how AOSP or Stock regulates consumption (some techniques don't work for us, such as app freezing), try to run attached script that will hotplug big core CPUs depending on your screen state. It will switch off the power-hungry CPUs while screen is off and will turn them on when you turn on the screen.

To run, install dependencies

# install required python package
devel-su zypper in python3-gobject

In terminal on phone, start

# run script
devel-su python cpupower.py

Keep the terminal running that script for a while and see whether it improves the battery consumption.

To judge cpufreq governors, I will have to fix collectd CPU frequency plugin first. It seems to ignore hotplugging of CPUs and shows some odd data (frequencies that are not expected to be there at all).

cpupower.zip

pagism · 2021-07-02T18:08:50Z

Thanks, it's running now but will take some time to observe any difference. Is there any command line tool that displays battery level? I used to have an awk script that was grabbing that info but I forgot the command ;-(

rinigus · 2021-07-02T18:15:33Z

Yes, it will take some time.

I should improve that script a bit further - looks like it resets interactive governor settings to default ones as soon as you switch on/off CPU. as a result it seems to get CPU stuck for longer in the high freq range.

Re battery: cat /sys/class/power_supply/battery/capacity

rinigus · 2021-07-03T06:16:57Z

OK, looks like Linux kernel itself when calculating CPU frequency distribution doesn't take into account whether CPU is switched off or not. Not much I can do on collectd side of things and would have to use caution while interpreting the data.

pagism · 2021-07-03T08:07:57Z

14h now battery percentage drop 18% (64 -> 46) with little use. the script might have crashed as it shows half a line print and no updates.

collecting data ideally should not add to the load, tgat can be tricky on highly tuned systems. then the other option we have is to collect data over longer periods. i am wondering if tgere is a way to create a techical load, tgen at least by observing consumption we get more accurate measurements.

rinigus · 2021-07-03T10:21:08Z

For CPUfreq scaling, Stock is using

H8324:/sys/devices/system/cpu/cpufreq/policy4/schedutil $ cat down_rate_limit_us                                            
0
H8324:/sys/devices/system/cpu/cpufreq/policy4/schedutil $ cat hispeed_freq                                                  
1574400
H8324:/sys/devices/system/cpu/cpufreq/policy4/schedutil $ cat hispeed_load                                                  
90
H8324:/sys/devices/system/cpu/cpufreq/policy4/schedutil $ cat pl
1
H8324:/sys/devices/system/cpu/cpufreq/policy4/schedutil $ cat up_rate_limit_us                                              
0

# for power efficient cpus
H8324:/sys/devices/system/cpu/cpufreq/policy0/schedutil $ cat down_rate_limit_us
0
H8324:/sys/devices/system/cpu/cpufreq/policy0/schedutil $ cat hispeed_freq
1209600
H8324:/sys/devices/system/cpu/cpufreq/policy0/schedutil $ cat hispeed_load
90
H8324:/sys/devices/system/cpu/cpufreq/policy0/schedutil $ cat pl
1
H8324:/sys/devices/system/cpu/cpufreq/policy0/schedutil $ cat up_rate_limit_us
0

For GPU bw:

H8324:/sys/class/devfreq/soc:qcom,gpubw # cat available_frequencies                                                       
0 381 572 762 1144 1571 2086 2597 2929 3879 4943 5931 6881
H8324:/sys/class/devfreq/soc:qcom,gpubw # cat cur_freq                                                                      
0
H8324:/sys/class/devfreq/soc:qcom,gpubw # cat max_freq                                                                      
6881
H8324:/sys/class/devfreq/soc:qcom,gpubw # cat min_freq                                                                      
0
H8324:/sys/class/devfreq/soc:qcom,gpubw # cat polling_interval                                                              
50
H8324:/sys/class/devfreq/soc:qcom,gpubw # cat governor                                                                      
bw_vbif

Few observations: gpu is frequently on 0 frequency if you don't use and scroll much. According to trans_stat, when active, frequencies 762 and 1144 are used. Probably others kick in at some other cases. 0 is not shown in stats, but is shown as current frequency in trans_stat as well.

For CPU bw:

H8324:/sys/class/devfreq/soc:qcom,cpubw # cat available_frequencies
2288 4577 6500 8132 9155 12298 14236
H8324:/sys/class/devfreq/soc:qcom,cpubw # cat available_governors
compute mem_latency bw_hwmon msm-vidc-llcc msm-vidc-ddr gpubw_mon bw_vbif msm-adreno-tz cpufreq userspace powersave performance simple_ondemand
H8324:/sys/class/devfreq/soc:qcom,cpubw # cat cur_freq
2288
H8324:/sys/class/devfreq/soc:qcom,cpubw # cat governor
bw_hwmon
H8324:/sys/class/devfreq/soc:qcom,cpubw # cat max_freq min_freq
14236
2288
H8324:/sys/class/devfreq/soc:qcom,cpubw # cat polling_interval
50
H8324:/sys/class/devfreq/soc:qcom,cpubw # cat target_freq
2288
H8324:/sys/class/devfreq/soc:qcom,cpubw # cat trans_stat
     From  :   To
           :      2288      4577      6500      8132      9155     12298     14236   time(ms)
*      2288:         0      1133        93        62        20        38         6   3744270
       4577:      1049         0       474       111        32        91        50    142340
       6500:       139       300         0       175        25        30        16     56860
       8132:        65       122        42         0        43        79        42     37360
       9155:        23        38         7         4         0        28        33     11980
      12298:        60       116        31        18         9         0        93     41620
      14236:        17        98        38        23         4        61         0    118940
Total transition : 4938

H8324:/sys/class/devfreq/soc:qcom,cpubw/bw_hwmon # cat bw_step                                                                                                                                                                                              
190
H8324:/sys/class/devfreq/soc:qcom,cpubw/bw_hwmon # cat decay_rate                                                                                                                                                                                           
90
H8324:/sys/class/devfreq/soc:qcom,cpubw/bw_hwmon # cat dow
down_count  down_thres
H8324:/sys/class/devfreq/soc:qcom,cpubw/bw_hwmon # cat down_count                                                                                                                                                                                           
3
H8324:/sys/class/devfreq/soc:qcom,cpubw/bw_hwmon # cat down_thres                                                                                                                                                                                           
0
H8324:/sys/class/devfreq/soc:qcom,cpubw/bw_hwmon # cat guard_band_mbps                                                                                                                                                                                      
0
H8324:/sys/class/devfreq/soc:qcom,cpubw/bw_hwmon # cat hist_memory                                                                                                                                                                                          
20
H8324:/sys/class/devfreq/soc:qcom,cpubw/bw_hwmon # cat hyst_length                                                                                                                                                                                          
10
H8324:/sys/class/devfreq/soc:qcom,cpubw/bw_hwmon # cat hyst_trigger_count
3
H8324:/sys/class/devfreq/soc:qcom,cpubw/bw_hwmon # cat idle_mbps
1600
H8324:/sys/class/devfreq/soc:qcom,cpubw/bw_hwmon # cat io_percent
50
H8324:/sys/class/devfreq/soc:qcom,cpubw/bw_hwmon # cat mbps_zones
2288 4577 6500 8132 9155 10681 
H8324:/sys/class/devfreq/soc:qcom,cpubw/bw_hwmon # cat sample_ms
4
H8324:/sys/class/devfreq/soc:qcom,cpubw/bw_hwmon # cat throttle_adj
0
H8324:/sys/class/devfreq/soc:qcom,cpubw/bw_hwmon # cat up_scale
250
H8324:/sys/class/devfreq/soc:qcom,cpubw/bw_hwmon # cat up_thres
10

rinigus · 2021-07-03T10:22:15Z

@pagism - try to press few Enters in the terminal and see if new messages will start to show up. I have seen that terminal gets messed up once in a while.

rinigus · 2021-07-03T10:25:13Z

Additional comment regarding stock - it doesn't use any CPU hotplugging, same as AOSP, I think. But Android workloads could be different from ours

pagism · 2021-07-03T10:56:41Z

I've ctr-c and restarted the script, seems to respond ok now. Hopefully does not require reboot(?).

Interesting, available frequencies in for GPU in xz3 do not go to 0, while in the stock one go:

[root@XperiaXZ3 soc:qcom,gpubw]# cat available_frequencies 
381 572 762 1144 1720 2086 2597 2929 3879 4943 5931 6881

the CPU frequencies are identical, available governors have some small differences too, and cpu stats look different:

[root@XperiaXZ3 soc:qcom,cpubw]# cat trans_stat 
     From  :   To
           :      2288      4577      6500      8132      9155     12298     14236   time(ms)
       2288:         0     28233      3278      1385       277       243      1068  25876518
*      4577:     18157         0     14987      3118       229       218      1072   2085124
       6500:      9943      5378         0      3118       221       151       458   1521455
       8132:      4597      1902       562         0       252       366       219    624932
       9155:       355       247        44        62         0       127       226     68131
      12298:       348       320        44       107        56         0       672     93742
      14236:      1084      1702       354       108        26       442         0   2251933
Total transition : 105756

and for gpu:

[root@XperiaXZ3 soc:qcom,gpubw]# cat trans_stat 
     From  :   To
           :       381       572       762      1144      1720      2086      2597      2929      3879      4943      5931      6881   time(ms)
*       381:         0         0         0      4115         0         0         0         0         0         0         0         0  29425330
        572:         0         0         0         0         0         0         0         0         0         0         0         0         0
        762:       311         0         0        12         0         0         0         0         0         0         0         0    485164
       1144:      3744         0       323         0        60         3         0         0         0         0         0         6   2566882
       1720:        60         0         0         2         0         1         0         0         0         0         0         0     48926
       2086:         0         0         0         3         0         0         3         0         0         0         0         0       773
       2597:         0         0         0         0         3         0         0         0         0         0         0         0      1427
       2929:         0         0         0         0         0         2         0         0         0         0         0         0       157
       3879:         0         0         0         1         0         0         0         2         0         0         0         0       387
       4943:         0         0         0         0         0         0         0         0         3         0         0         0       103
       5931:         0         0         0         0         0         0         0         0         0         3         0         0       147
       6881:         0         0         0         3         0         0         0         0         0         0         3         0      2115
Total transition : 8663

N.B. current notes were taken via an ssh connection, and the script running in a terminal, screen was off.

rinigus · 2021-07-03T12:04:27Z

When switching to schedutil for CPUs 0-3 (policy0), I always get a crash. Sometimes, dmesg from pstore has something like

[ 1195.018006] healthd: battery l=91 v=4074 t=37.0 h=2 st=3 c=258 fc=2520000 chg=
[ 1197.415508] BUG: scheduling while atomic: sshd/8735/0x00000004

Example of a crash:

Jul 03 14:58:46 XperiaXZ2Compact kernel: BUG: scheduling while atomic: gdbus/6407/0x00000005
Jul 03 14:58:46 XperiaXZ2Compact kernel: Modules linked in:
Jul 03 14:58:46 XperiaXZ2Compact kernel: CPU: 2 PID: 6407 Comm: gdbus Tainted: G        W       4.14.232-gd88c66b3138a-dirty #2
Jul 03 14:58:46 XperiaXZ2Compact kernel: Hardware name: Sony Mobile Communications. Apollo(SDM845 v2.1) (DT)
Jul 03 14:58:46 XperiaXZ2Compact kernel: Call trace:
Jul 03 14:58:46 XperiaXZ2Compact kernel:  dump_backtrace+0x0/0x188
Jul 03 14:58:46 XperiaXZ2Compact kernel:  show_stack+0x14/0x1c
Jul 03 14:58:46 XperiaXZ2Compact kernel:  dump_stack+0xcc/0x10c
Jul 03 14:58:46 XperiaXZ2Compact kernel:  __schedule_bug+0x50/0x70
Jul 03 14:58:46 XperiaXZ2Compact kernel:  __schedule+0x9b8/0xca0
Jul 03 14:58:46 XperiaXZ2Compact kernel:  schedule+0x70/0x90
Jul 03 14:58:46 XperiaXZ2Compact kernel:  schedule_timeout+0x388/0x44c
Jul 03 14:58:46 XperiaXZ2Compact kernel:  wait_for_common+0xa4/0x114
Jul 03 14:58:46 XperiaXZ2Compact kernel:  wait_for_completion_timeout+0x10/0x18
Jul 03 14:58:46 XperiaXZ2Compact kernel:  rpmh_write+0x160/0x204
Jul 03 14:58:46 XperiaXZ2Compact kernel:  rpmh_regulator_send_aggregate_requests+0x3e8/0x4ec
Jul 03 14:58:46 XperiaXZ2Compact kernel:  rpmh_regulator_arc_set_voltage_sel+0x44/0x9c
Jul 03 14:58:46 XperiaXZ2Compact kernel:  _regulator_do_set_voltage+0x2a4/0x5e4
Jul 03 14:58:46 XperiaXZ2Compact kernel:  regulator_set_voltage_unlocked+0x204/0x2c8
Jul 03 14:58:46 XperiaXZ2Compact kernel:  regulator_set_voltage+0x4c/0x80
Jul 03 14:58:46 XperiaXZ2Compact kernel:  clk_update_vdd+0x94/0x1b0
Jul 03 14:58:46 XperiaXZ2Compact kernel:  clk_calc_subtree+0x1d0/0x2d0
Jul 03 14:58:46 XperiaXZ2Compact kernel:  clk_calc_new_rates+0x384/0x3f0
Jul 03 14:58:46 XperiaXZ2Compact kernel:  clk_calc_new_rates+0x3e0/0x3f0
Jul 03 14:58:46 XperiaXZ2Compact kernel:  clk_core_set_rate_nolock+0x98/0x410
Jul 03 14:58:46 XperiaXZ2Compact kernel:  clk_set_rate+0x84/0x110
Jul 03 14:58:46 XperiaXZ2Compact kernel:  osm_cpufreq_target_index+0xa4/0xd4
Jul 03 14:58:46 XperiaXZ2Compact kernel:  osm_cpufreq_fast_switch+0xe4/0x11c
Jul 03 14:58:46 XperiaXZ2Compact kernel:  cpufreq_driver_fast_switch+0x34/0x58
Jul 03 14:58:46 XperiaXZ2Compact kernel:  sugov_update_commit+0x78/0x194
Jul 03 14:58:46 XperiaXZ2Compact kernel:  sugov_update_shared+0x3e0/0x434
Jul 03 14:58:46 XperiaXZ2Compact kernel:  attach_entity_load_avg+0xb8/0x180
Jul 03 14:58:46 XperiaXZ2Compact kernel:  enqueue_task_fair+0xf8c/0x266c
Jul 03 14:58:46 XperiaXZ2Compact kernel:  ttwu_do_activate+0xc0/0x244
Jul 03 14:58:46 XperiaXZ2Compact kernel:  try_to_wake_up+0x430/0x610
Jul 03 14:58:46 XperiaXZ2Compact kernel:  default_wake_function+0x14/0x1c
Jul 03 14:58:46 XperiaXZ2Compact kernel:  pollwake+0x4c/0x60
Jul 03 14:58:46 XperiaXZ2Compact kernel:  __wake_up_locked_key+0x50/0x7c
Jul 03 14:58:46 XperiaXZ2Compact kernel:  eventfd_write+0x1c0/0x210
Jul 03 14:58:46 XperiaXZ2Compact kernel:  __vfs_write+0x38/0x110
Jul 03 14:58:46 XperiaXZ2Compact kernel:  vfs_write+0xc8/0x184
Jul 03 14:58:46 XperiaXZ2Compact kernel:  SyS_write+0x60/0xa8
Jul 03 14:58:46 XperiaXZ2Compact kernel:  el0_svc_naked+0x34/0x38
Jul 03 14:58:46 XperiaXZ2Compact kernel: BUG: scheduling while atomic: gdbus/6407/0xfffffffd
Jul 03 14:58:46 XperiaXZ2Compact kernel: Modules linked in:
Jul 03 14:58:46 XperiaXZ2Compact kernel: CPU: 2 PID: 6407 Comm: gdbus Tainted: G        W       4.14.232-gd88c66b3138a-dirty #2
Jul 03 14:58:46 XperiaXZ2Compact kernel: Hardware name: Sony Mobile Communications. Apollo(SDM845 v2.1) (DT)
Jul 03 14:58:46 XperiaXZ2Compact kernel: Call trace:
Jul 03 14:58:46 XperiaXZ2Compact kernel:  dump_backtrace+0x0/0x188
Jul 03 14:58:46 XperiaXZ2Compact kernel:  show_stack+0x14/0x1c
Jul 03 14:58:46 XperiaXZ2Compact kernel:  dump_stack+0xcc/0x10c
Jul 03 14:58:46 XperiaXZ2Compact kernel:  __schedule_bug+0x50/0x70
Jul 03 14:58:46 XperiaXZ2Compact kernel:  __schedule+0x9b8/0xca0
Jul 03 14:58:46 XperiaXZ2Compact kernel:  schedule+0x70/0x90
Jul 03 14:58:46 XperiaXZ2Compact kernel:  schedule_hrtimeout_range_clock+0x78/0x188
Jul 03 14:58:46 XperiaXZ2Compact kernel:  schedule_hrtimeout_range+0x10/0x18
Jul 03 14:58:46 XperiaXZ2Compact kernel:  do_sys_poll+0x250/0x5b8
Jul 03 14:58:46 XperiaXZ2Compact kernel:  SyS_ppoll+0x168/0x240
Jul 03 14:58:46 XperiaXZ2Compact kernel:  el0_svc_naked+0x34/0x38

pagism · 2021-07-03T13:47:04Z

hm, not very informative to me unfortunately, can we get any help from xda community? or they are mainly now into aosp-11? makes me wondering how Jolla got relatively good quality aosp

rinigus · 2021-07-03T15:34:17Z

They may use the same interactive governor as we do. I don't think this is altered from the one set by AOSP.

All in all, we are not too bad off. I will

check if the crash happens with AOSP. If it does, file issue upstream
update the script a bit and let's test it more. While Android does not seem to use hotplugging as far as I can see on Sony AOSP nor stock, it may make sense to use it on SFOS. If this POC works, I can write a small daemon for it. Will discuss it on SFOS channel as well, but first polish the script a bit.
GPU is separate issue and we will handle it separately. But, it maybe integrated with handling CPU as well - I will look whether to make the script aware of it.

pagism · 2021-07-06T06:38:17Z

my general feeling is very similar, is that issue at the aosp layer or further higher in the stack? should we run some tests running the aosp only?

lal883 · 2021-07-06T07:20:09Z

From the discussion on Sony channel:

Excessive idle drain is a known issue for Tama 4.14. According to Marijn:

Idle drain is at 12mA, bumps to 24mA at a random moment, and to 49 later It used to always go down to 6mA on 4.9 (just like Kumano on 4.14) That's the difference between 1%/h overnight and 1% for a full night (and during the day at idle)

On SFOS, according to my tests: drain for me was between 26mA-57mA, averaging on 32mA during a night with only calls accepted on sim (no net) and earlier 1-2% for a full night was a norm in these conditions, not on 4.14 anymore.

Woah, hitting 6mA on idle on AOSP, that is great figure. If I understand it right, this is not the case with SFOS even with 4.9, correct? I am seeing ~22mA as average (never below 16) when only mobile network is on to accept calls. Running 4.9 on SFOS 4.0.1, Apollo.

Would it be possible to disable some sensors (like pressure sensor) and test if those are consuming power even when not in use? Like, disable from an even lower level than the OS itself?

rinigus · 2021-07-06T07:42:41Z

I presume this is in flight mode. In flight mode on AOSP9-based SFOS I am quite sure we can get very low in this case.

@lal883: How do you measure power consumption? I let collectd do it's work for some time and take an average for few hours. Maybe should repeat that test on AOSP9 SFOS - would have to reflash then...

lal883 · 2021-07-06T08:31:46Z

I run a script to record the current consumption to a file at 1 min intervals. It doesn't record when the phone is sleeping though, as I understand.

Collected data looks like this
(time | % | BMS reported remaining time | current)
10:38 - 51 % | 10 hr 17 min | 20 mA
10:42 - 51 % | 10 hr 17 min | 21 mA
10:47 - 51 % | 10 hr 17 min | 22 mA
10:50 - 51 % | 10 hr 17 min | 22 mA
10:55 - 51 % | 10 hr 17 min | 22 mA
10:58 - 51 % | 10 hr 17 min | 22 mA
11:03 - 51 % | 10 hr 17 min | 22 mA

I can do the collectd test and report back too. Will also check flight mode.

rinigus · 2021-07-06T09:26:14Z

Good point regarding not recording at sleep. In this respect, drop in battery % is probably most reliable. Just requires longer measurement.

pagism · 2021-07-06T15:38:02Z

is it reasonable to expect a newer release of the aosp blobs? the current release is from dec 2020

rinigus · 2021-07-06T15:46:55Z

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.

rinigus · 2021-07-06T17:21:23Z

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!

pagism · 2021-07-06T18:07:36Z

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?

rinigus · 2021-07-06T19:00:33Z

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.

rinigus · 2021-07-07T17:35:57Z

For reference, on AOSP9 based SFOS port

Apollo in flight mode: 0.25%/h drain, 160s suspend on average. This is VS 0.9%/h on AOSP10 based port
Apollo with SIM card in 4G accepting calls only (no net): 0.9%/h, 5s suspend; This is VS 1%/h on different device (akari) in AOSP10. Not sure I can compare it like that, though, as devices are different and I would have to retest on the same device...

pagism · 2021-07-07T18:38:52Z

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?

rinigus · 2021-07-07T18:43:36Z

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 ...

pagism · 2021-07-07T18:51:33Z

thanks, it's important to use the same tools, i was a bit hesitant running collectd not knowning its overhead.

rinigus · 2021-07-07T18:55:41Z

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

lal883 · 2021-07-08T04:35:40Z

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
`

rinigus · 2021-07-08T06:08:02Z

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?

lal883 · 2021-07-08T06:21:46Z

@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

rinigus · 2021-07-08T06:27:34Z

Thanks!

pagism · 2021-07-08T06:42:49Z

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.

rinigus · 2021-07-08T06:53:01Z

@pagism : what about battery %/h? feeling what it was before? as uA are probably picked up during resume moments

pagism · 2021-07-08T07:07:28Z

@rinigus observing the battery % graph consumption is 1%/h
can we have a csv form of yhe graph too?

rinigus · 2021-07-08T07:08:39Z

csv is maybe possible, but not trivial. easiest is to choose time window and then just calculate %/h from min/max values

rinigus · 2021-07-08T18:24:57Z

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

Apollo in flight mode: 0.25%/h drain, 160s suspend on average. This is VS 0.9%/h on AOSP10 based port
Apollo with SIM card in 4G accepting calls only (no net): 0.9%/h, 5s suspend; This is VS 1.17%/h in AOSP10, suspend times 5.5s.

So, when used with SIM, the difference was not that massive. Here, AOSP10 was using zgovernor, not used in AOSP9

pagism · 2021-07-08T18:56:28Z

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.

rinigus · 2021-07-08T20:09:17Z

Agreed, such testing is pretty much what we do these days

rinigus · 2021-07-09T06:18:05Z

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

rinigus · 2021-07-14T06:17:50Z

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.

rinigus added the hybris-10 AOSP 10 based port label Jun 30, 2021

rinigus mentioned this issue Jun 30, 2021

hybris-10 XZ3 glitch on screen while swiping or unlocking #150

Closed

rinigus changed the title ~~hybris-10 power consumption while idling for xz3~~ Power consumption while idling Jul 6, 2021

lal883 mentioned this issue Oct 15, 2021

USB audio support is disabled in PulseAudio #94

Closed

Power consumption while idling #154

Power consumption while idling #154

Comments

pagism commented Jun 29, 2021

rinigus commented Jun 29, 2021

pagism commented Jun 29, 2021

rinigus commented Jun 29, 2021

pagism commented Jun 29, 2021

rinigus commented Jun 29, 2021

pagism commented Jun 29, 2021

rinigus commented Jun 30, 2021

pagism commented Jun 30, 2021

pagism commented Jul 1, 2021

rinigus commented Jul 1, 2021

pagism commented Jul 1, 2021

rinigus commented Jul 1, 2021

rinigus commented Jul 1, 2021

pagism commented Jul 1, 2021

rinigus commented Jul 2, 2021

pagism commented Jul 2, 2021

rinigus commented Jul 2, 2021

pagism commented Jul 2, 2021

rinigus commented Jul 2, 2021

rinigus commented Jul 3, 2021

pagism commented Jul 3, 2021

rinigus commented Jul 3, 2021

rinigus commented Jul 3, 2021

rinigus commented Jul 3, 2021

pagism commented Jul 3, 2021

rinigus commented Jul 3, 2021 • edited Loading

pagism commented Jul 3, 2021

rinigus commented Jul 3, 2021

pagism commented Jul 6, 2021

lal883 commented Jul 6, 2021

rinigus commented Jul 6, 2021

lal883 commented Jul 6, 2021

rinigus commented Jul 6, 2021

pagism commented Jul 6, 2021

rinigus commented Jul 6, 2021

rinigus commented Jul 6, 2021

pagism commented Jul 6, 2021

rinigus commented Jul 6, 2021

rinigus commented Jul 7, 2021

pagism commented Jul 7, 2021

rinigus commented Jul 7, 2021

pagism commented Jul 7, 2021

rinigus commented Jul 7, 2021 • edited Loading

lal883 commented Jul 8, 2021 • edited Loading

rinigus commented Jul 8, 2021

lal883 commented Jul 8, 2021

rinigus commented Jul 8, 2021

pagism commented Jul 8, 2021

rinigus commented Jul 8, 2021

pagism commented Jul 8, 2021

rinigus commented Jul 8, 2021

rinigus commented Jul 8, 2021

pagism commented Jul 8, 2021

rinigus commented Jul 8, 2021

rinigus commented Jul 9, 2021 • edited Loading

rinigus commented Jul 14, 2021

rinigus commented Jul 3, 2021 •

edited

Loading

rinigus commented Jul 7, 2021 •

edited

Loading

lal883 commented Jul 8, 2021 •

edited

Loading

rinigus commented Jul 9, 2021 •

edited

Loading