PW4 Minimizing battery consumption

[handyguy]

Hi, starting a new thread on how to minimize the Kindle battery consumption.
Personally, I am running a python clock app on a PW4 and am trying to get the longest life between charges. I have run a number of different experiments, and they all get about the same life (all using rtcwake):
1) Full clock app waking up the processor every minute (260 lines of code).
2) Stripped down app displaying only minutes digit (28 lines).
3) Stripped down app waking every minute, not displaying anything (27 lines).
Note that wifi is mostly off for 1 and always off for 2 & 3
All three consume about .5% battery/hour - no difference!

I was going to completely re-write the app to make the code more efficient, but it seems the few hundred lines of code make little difference in consumption, so it is not worth the effort.

Some options for greater efficiency:
1) Use Powersave - I have not been able to make that work on the PW4, and in any case, I don't expect much change - everything will run slower, but longer.
2) stop or kill a few unnecessary tasks - I don't think there are any that utilize much cpu.

Currently the clock will run about 8 days between charges.

Any other ideas?

[handyguy]

# test.py
import datetime
import os
import subprocess
import sys
import time
from time import sleep
def display_digit4(x):
    os.system('echo 0 | fbink -i {}.png -g x=762 -q'.format(x))
try:
    subprocess.Popen(['lipc-set-prop', 'com.lab126.cmd', 'wirelessEnable', '0'], stdout=subprocess.PIPE)
    sp = subprocess.Popen(['gasgauge-info', '-s'], stdout=subprocess.PIPE)
    bat, _ = sp.communicate()
    bat = int(bat)
    font = '/mnt/us/clock/bahnschrift.ttf'
    command = 'fbink -t regular={},px=35,top=1410,format "BATTERY= {}"  -mec'.format(font,bat)
    os.system(command)
    subprocess.Popen(['lipc-set-prop', 'com.lab126.powerd', 'preventScreenSaver', '1'], stdout=subprocess.PIPE)
    while True:
        now = datetime.datetime.now()
        digit4 = now.minute % 10
#       display_digit4(digit4)
        sleep(1)
        command = "rtcwake -d /dev/rtc1 -m mem -s 59"
        subprocess.Popen(command, shell=True, stdout=subprocess.PIPE)

except KeyboardInterrupt:
	print ("kb interrupt")
finally:
    subprocess.Popen(['lipc-set-prop', 'com.lab126.cmd', 'wirelessEnable', '1'], stdout=subprocess.PIPE)

[mergen3107]

Why do you need exactly python for that?
I mean, you essentially just draw time values using fbink. Why don't you try making a bash script running in the background?
I think that would save some cpu burden.

[NiLuJe]

Sidebar: There's a Python fbink module, no need to spawn the CLI tool. (fork is expensive).

In this context, you're already fork'ing for lipc anyway, so, eeeeh.

Still, ought to be mentioned .

@mergen3107: Python/bash is unlikely to be much of an issue here. It's going to be expensive to spawn (more so for Python), but that's it. I'm assuming this *isn't* spawned every time, but instead spawned only once (i.e., a daemon).

Once that's out of the way, Python is actually likely to be less awful than bash, because bash isn't even bash here, but an old and ugly busybox ash .

That said, nothing computationally expensive is really tied to the language here, as far as the internal logic goes.

If you *do* need to spawn stuff often, you've kind of already lost before even starting, so, back to the design phase .

----

In which case: that leaves you basically C (and/or LuaJIT). There's an open basic header for using lipc in C, f.g. (c.f., https://github.com/yparitcher/kindle-zmanim for a recent example).

[pazos]

eight days is a good mark.

I've run a clock app on a kobo aura hd the last two/three? years: the app:

does a partial update of the clock area each minute (obvious, but...)
does a full refresh of the clock area each 15 minutes
connects to wifi and retrieves weather each hour.
has the light button repurposed as a snooze button, to light the screen a few seconds and see the data.

I don't use rtcwake, just leave the processor idle (with conservative governor). I got about 48 hours of autonomy without using the light.

In the past I did a few things to improve battery life:

use a ramdisk for the rootfs instead of a block device
remove kernel options that I don't need
reduce the frontlight level while snoozing.

I had fun but I probably didn't squeeze more than a few minutes per cycle, so meh.

I don't have a kindle (or much kindle inner knowledge) but I guess you can stop any running services/frameworks and see if that makes any difference.

[handyguy]

Originally Posted by mergen3107

Why do you need exactly python for that?
I mean, you essentially just draw time values using fbink. Why don't you try making a bash script running in the background?
I think that would save some cpu burden.

I am more familiar with Python, so I used that. Another poster did write a clock with bash and had worse battery life.

[handyguy]

Originally Posted by NiLuJe

Sidebar: There's a Python fbink module, no need to spawn the CLI tool. (fork is expensive).

In this context, you're already fork'ing for lipc anyway, so, eeeeh.

Still, ought to be mentioned .

@mergen3107: Python/bash is unlikely to be much of an issue here. It's going to be expensive to sspawn, but that's it. I'm assuming this *isn't* spawned every time, but instead spawned once (i.e., a daemon).

Once that's out of the way, Python is actually likely to be less awful than bash, because bash isn't even bash here, but an old and ugly busybox ash .

If you *do* need to spawn stuff often, you've kind of already lost before even starting, so, back to the design phase .

There's native FBINK support in Python? Cool, will make my code simpler!

[NiLuJe]

I do think the CPU sched would be an easy win: nothing is really computationally expensive *at all*, so I don't buy the "it'll take longer" theory . The lowest power step is still in the 3 digits realm, IIRC, it's not slowed down to a crawl .

And I'm assuming you're already bringing down lab126_gui, which doesn't leave much running IIRC (powerd? blanket? been a while ). You probably don't need anything else than powerd (if even that, I have a vague memory of it being the thing needed to handle power button events properly on some devices, but that's it), actually.

Someone posted an up-to-date deptree of the upstart jobs fairly recently, IIRC.

[NiLuJe]

As for py-fbink, yep, it's just an FFI wrapper, but it's bundled with my Python builds (Pillow & wand, too, among other things) .

[NiLuJe]

Also, another free fork removal tip: don't call gasgauge-info, there's a sysfs entry for that.

(Depends on the device, though)

[NiLuJe]

You can also implement rtcwake in pure-Python, as it's basically timestamp, localtime/utc & ioctls shenanigans.

(To that end, I also ship https://github.com/vpelletier/python-ioctl-opt, although I've never used it myself).

@Frenzie did it for Kobo in KOReader. (https://github.com/koreader/koreader...er/ffi/rtc.lua && https://github.com/koreader/koreader.../wakeupmgr.lua).
Fair warning: the utc vs. localtime crap is a bitch to get right. If you can afford it, the way rtcwake does it (basically switching the whole thread's TZ) is probably less gnarly.

Someone may have already done that for Python, actually, haven't looked .

[NiLuJe]

I'd also probably prefer https://docs.python.org/3/library/su...subprocess.run to Popen, especially if you don't need to capture the output, but that's extremely nitpicky (the overhead isn't really in the mess of dupe/pipe needed to capture output, it's the fork. And on the old glibc the Kindle runs, posix_spawn still sucks, so there's no silver bullet here).

(Or, god forbid, os.system(), which spawns an extra shell for nothing).

[handyguy]

The skeleton code consumed the same amount of battery .5%/hour. There were only a few lines of code and the rtcwake call in the main loop. All the other calls execute only once at the start or not at all in this code. This would provide the lower bound of battery utilization, with the simplest of code. I guess 8 days is all we can get. I did check some of the tasks for potential stopping, but none of the likely candidates use much cpu.

[NiLuJe]

Random question: how are you suspending the device? Because setting up an rtc wake is all well and good, but it's kind of a moot point if the device never actually suspends ^^.

EDIT: Err, duh. Via the rtcwake tool. Never ask questions at 6AM. .

Still, it's worth checking if it actually suspends properly, and/or whether whatever the Kindle does on its own matches that.

(i.e., there's probably a powerd lipc prop to enter suspend).

[handyguy]

I believe it is suspending - It does not respond to screen touches. I invoke the code from the CLI with the keyboard at the bottom of the screen. If it's awake, the keyboard appears when keys are touched (for example if I use sleep instead of rtcwake.) It can be very difficult to exit the clock from rtcwake, and often a reset/reboot is required - correction, tapping the power button wakes the code up and cntl-c can be entered.