PW4 Minimizing battery consumption

[mergen3107]

Some random design thoughts just for seeing a complete picture, if you don’t mind:
1) have you tried different intervals, let’s say every 5 min instead of 1 min?
2) have you tried to actually draw a smaller font clock? Does it affect the battery? I mean, fewer pixels, less power, right?
3) have you tried to lower cpu clocks before going to suspend? There is a project by knc1 about manually lowering cpu clocks on Kindles (Kindle response gets slower of course, but in your case this would mean probably slower redraw times and longer time to wake up). Not sure if it works with PW4

[kdusr]

if your script wrote in py3.x, change it to py2.7 and add those two line at head>

import sys
sys.setcheckinterval(2048) #set this value to 2048(default is 100) or higher value, test it again

.
.
.
digit4 = now.minute % 10
# display_digit4(digit4)
sleep(10)
.
.
.

[handyguy]

A smaller clock/text would not matter as the final benchmark script drew nothing and used the same current. I am using Python 2.7 - do you think it's more efficient than 3? What do you think the setcheckinterval will do?
I am thinking about running another benchmark with a longer interval; will report back.

For the Kindle to last multiple weeks in use as an e-reader, it must be entering a deeper sleep than just rtcwake -m mem ?

Thanks all for the suggestions!

[NiLuJe]

@kdusr: Hmm, reading the doc (https://docs.python.org/3.4/library/...tcheckinterval && https://docs.python.org/3.4/library/...switchinterval) this should have no bearings on this, as this is single-threaded, and not really subject to any kind of signals (or, really, anything even remotely computationally intensive as far as Python is concerned).

Not a Python wizard, so open to more details, instead of a random "try this" drive-by .

@handyguy: Those "multiple weeks" stats are usually for 30 minutes of "awake" time each day, so, *one* wakeup per-day, and spending most of its time asleep. And even if you forget those kind of stats, and assume that, say, you can achieve between 24 to 48H of "screen on" time (warning: random number ), that'd be mostly contiguous sessions, with very few sleep/wakeups cycles. Not really applicable to your use case.

The overhead of sleeping/waking up is probably much higher than that all on its own. What takes the cake is toggling WiFi, though, as bringing the radio up is murder for the battery.

I think @ilovejedd ran a bunch of tests a while back checking how long the battery actually lasted with the device just plain asleep, never woken up, you might want to dig that up .

That was done to test the "deep sleep" (or whatever it's called) feature of some newer Kindles like the latest Oasis, which can optionally do a suspend to disk (-ish, IIRC).

[mergen3107]

I also thought about one thing. It might sound controversial and against common sense, but my scientific research experience gifted me many nice revelations this way

So now you have:
— Enter Kindle to sleep
— Draw current time, send to sleep
— After t<60 s, wake up, draw another time, send to sleep
— repeat until terminated.

I am thinking, what are the wake up routines that Kindle goes through? Are they more power hungry at startup compared to other processes running during wake up over a specific time interval? Maybe right now it is not that energy-efficient to put them to sleep and wake up every minute?
How about doing a proper wake not every single minute, but once a 3-minute (5, 10, etc) interval?

P. S. I can also take part in the long-term testing routines if you don’t mind During weekdays there are 2-3 days when I have no time to touch my Kindle, so I can run, let’s say, a 24-hour test and report. Then you can collect all such data (routine type and its time) to see how they compare one to another.

[NiLuJe]

@mergen3107: I'm not sure how practical a mixed workflow would turn out (if I understood you properly ), but I do agree with the reasoning: another interesting data point would indeed be doing that with no suspend at all (i.e., just sleep).

You'd of course want to do that w/ the powersave governor (and/or manually pinned to the lowest clockrate, if that's supported by the sched/governor on the PW4).

(And inhibit the Kindle's own suspend routines, which probably simply entails stopping powerd).

[mergen3107]

NiLuJe, looks like we were typing similar ideas about wake up/sleep efficiency at the same time
I was typing from my phone though :P

[mergen3107]

Yeah, that’s exactly what I mean by “ It might sound controversial and against common sense”, but only real tests can tell the truth

Yes, sure, I’ll try it with the CPU governor. Last time I used it was with my old Kindle Touch on 5.3.7, but I hope Amazon didn’t break necessary things along the way to 5.9.7 on my current PW3

[NiLuJe]

Yeah, plus my own habit of editing some posts for over 15/30 minutes doesn't help ^^.

[kdusr]

sys.setcheckinterval(interval)
Set the interpreter’s “check interval”. This integer value determines how often the interpreter checks for periodic things such as thread switches and signal handlers. The default is 100, meaning the check is performed every 100 Python virtual instructions. Setting it to a larger value may increase performance for programs using threads. Setting it to a value <= 0 checks every virtual instruction, maximizing responsiveness as well as overhead.

advanced option
your script imported 5 python modules, I guess all of funcations in your script need only two modules: ctypes, sys

[NiLuJe]

You're just quoting back the doc I just linked at me, which doesn't really enlighten anyone .

As for imports, he does use most of it, so while making sure you're not importing useless stuff is certainly good practice, it's not terribly relevant here .

[j.p.s]

Originally Posted by NiLuJe

I think @ilovejedd ran a bunch of tests a while back checking how long the battery actually lasted with the device just plain asleep, never woken up, you might want to dig that up .

That was done to test the "deep sleep" (or whatever it's called) feature of some newer Kindles like the latest Oasis, which can optionally do a suspend to disk (-ish, IIRC).

Those tests covered a lot of cases, but not "deep sleep" (or whatever it's called).

I am still very interested in seeing results that kind of test.

[Junket]

Originally Posted by NiLuJe

I think @ilovejedd ran a bunch of tests a while back checking how long the battery actually lasted with the device just plain asleep, never woken up, you might want to dig that up .

That was done to test the "deep sleep" (or whatever it's called) feature of some newer Kindles like the latest Oasis, which can optionally do a suspend to disk (-ish, IIRC).

Referenced thread

The result, e.g. about 5% drain /month (PW4, deep sleep) implies zero processor activity as the discharge rate is what you would expect for a battery alone sitting on a shelf (2% per month self-discharge, plus 2 - 3% per month for the battery protection circuit).

[j.p.s]

Originally Posted by Junket

Referenced thread

The result, e.g. about 5% drain /month (PW4, deep sleep) implies zero processor activity as the discharge rate is what you would expect for a battery alone sitting on a shelf (2% per month self-discharge, plus 2 - 3% per month for the battery protection circuit).

So deep sleep renders airplane mode irrelevant if that is true. That means that periodical subscriptions would not download until user initiated wakeup. Also, if OTA updates are enabled, they would usually only happen when the reader is in use. Oh joy, get out the reader to occupy an unexpected brief wait, watch the UI freeze during the download then go into a glacial reboot.

[Junket]

Originally Posted by j.p.s

So deep sleep renders airplane mode irrelevant if that is true.

Well perhaps not quite irrelevant. There is more drain if the Kindle is put into deep sleep without airplane mode. So there is probably some minimal watchdog activity going on. But battery drain still doesn't stray far from what we would expect from simple self-discharge of the battery.

Deep sleep + airplane mode was about 5% drain /month
Manual shutdown command brings that down to 3% drain /month

Which for the PW4 is probably just the residual self-discharge. And FWIW, an apparently efficient battery protection circuit. As ever, we can't have all of our cake and eat it too. There are always trade-off's and they may well impact boot time as you implied. It would take a lot more trials to flesh out the fine details of battery use for every scenario and there are confounding factors such as the non-linear battery drain from 100% charge state i.e. we would see a more linear drain if the test started at 95% or less.

But ilovejedd has done most of the work for us and we can see the relative battery drain in common usage situations. We can pick our poison at least in terms of ease of use vs maximized battery life.