Power consumption while idling

pagism commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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

rinigus commented 3 years ago

No, not yet. let me check few things first

pagism commented 3 years ago

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

pagism commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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

rinigus commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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

pagism commented 3 years ago

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

rinigus commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

@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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

Indeed it's that bad, even the GPU issue is ok-ish providing that it saves battery.

Actually without understanding much it seems that CPU policy is one scale higher than the stock version (4577 vs 2288), and GPU is similar (381 vs 0). Does that also explains the fact that tama devices on ssh are a lot more responsive than xa2?

Let's see what the others think, happy to try the new script. BTW I was thinking to upgrade the handler and print e.g. battery level or stats, or that will become heavy weighted?

rinigus commented 3 years ago

Re CPU being higher: it is not in general, just snapshots from two cases.

Re responsive - it could be due to less CPU sleep, not sure. but CPU is way faster in Tama

Re GPU: will ask why they removed it

rinigus commented 3 years ago

AOSP10 does allow to use schedutil and I observed a crash only once so far.

AOSP10 Issue filed: https://github.com/sonyxperiadev/bug_tracker/issues/705

pagism commented 3 years ago

hopefully we get something good from all this, thanks for your effort!

pagism commented 3 years ago

I run the script overnight, 5% drop in 9 hours (95 -> 90) not bad.

rinigus commented 3 years ago

I think the daemon can help us a lot and it makes sense as well. There are more issues with schedutil (see bug in AOSP10 repo, reference above), so we will probably stick with the current governors.

I will tune the script a bit and then we can test it further.

rinigus commented 3 years ago

Started making tests on suspend as well.

On clean SFOS install:

fully offline: suspend in excellent. Hitting 600 and 1200 seconds per suspend, or similar.
no network, 4G SIM: 6 second average
no network, 4G SIM: 7 second average
no network, 2G SIM: 67 seconds average

So, looks like 4/3G are leading to interrupts that wake up the device. Which is not surprising, I expect the same on AOSP

rinigus commented 3 years ago

I have replaced the script with a small daemon that does the same: https://github.com/rinigus/zgovernor

It can be installed from Tama repos using zypper in zgovernor (just remember to refresh repositories).

On install, the daemon is automatically enabled and started. You could follow its messages using journalctl or systemctl status zgovernor

In addition to previous changes, it also switches power-efficient CPUs to conservative cpufreq governor on screen going off. As you could see in its config file (installed at /etc/zgovernor.ini and visible at https://github.com/rinigus/zgovernor/blob/master/example/zgovernor.ini), it will be easy to expand it to handle GPU as well.

Would be good to test it and see if it improves the battery consumption. At the same time, device shouldn't be slow either :)

pagism commented 3 years ago

Installed and running now. upon device restart I get:

[root@XperiaXZ3 defaultuser]# systemctl status zgovernor
● zgovernor.service - Z Governor
   Loaded: loaded (/usr/lib/systemd/system/zgovernor.service; enabled; vendor preset: enabled)
   Active: inactive (dead)

is that right? I had to restart it manually

rinigus commented 3 years ago

That was a bug in service file - thank you for reporting it! Please update, new version is uploaded

rinigus commented 3 years ago

Saw a glitch in the daemon that prevented CPU sleep. Maybe similar (if it was) to your case where python script hanged somewhere. Will have to make it more robust.

rinigus commented 3 years ago

This time it was /usr/bin/msyncd with long suspend inhibition for some reason, not the daemon. So, just would have to keep an eye on it.

pagism commented 3 years ago

power consumption has improved dramatically i am closing now 24h and the drop is 95 -> 73, it was 82 earlier but i used few apps the last hour

rinigus commented 3 years ago

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.

pagism commented 3 years ago

pity isn't it? disappointing quality of tama aosp is like that

rinigus commented 3 years ago

it is pity, indeed. in the end, AOSP depends on BLOBs and their quality. So, it is probably down to the quality of those not AOSP itself.

Which we will have to take into account and discuss in some public forum on what to do with the port. SFO probably.

rinigus commented 3 years ago

Running Apollo in flight-mode leads to battery drain 0.9%/h - 23mA on average. At the same time suspend was excellent, hitting ~600s per suspend on average.

Akari with SIM card in call accepting mode, no network, had drain ~1%/h - 29mA. Suspend time was about 9s per one suspend on average.

So, looks like drain is caused by something in device that does always consume energy regardless of suspend state.

pagism commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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

sailfishos-sony-tama / main

Power consumption while idling #154