View Single Post
Old 10-20-2017, 04:47 PM   #72
mdp
Wizard
mdp ought to be getting tired of karma fortunes by now.mdp ought to be getting tired of karma fortunes by now.mdp ought to be getting tired of karma fortunes by now.mdp ought to be getting tired of karma fortunes by now.mdp ought to be getting tired of karma fortunes by now.mdp ought to be getting tired of karma fortunes by now.mdp ought to be getting tired of karma fortunes by now.mdp ought to be getting tired of karma fortunes by now.mdp ought to be getting tired of karma fortunes by now.mdp ought to be getting tired of karma fortunes by now.mdp ought to be getting tired of karma fortunes by now.
 
Posts: 1,481
Karma: 9010563
Join Date: Jul 2013
Device: none
Quote:
Originally Posted by guest View Post
No (but I did remove lots of system apps):

shell@android:/ $ top -n 1 -m 5
[...]
And there is a constant small usage of the CPU, which affects the battery:

shell@android:/ $ dumpsys cpuinfo
Load: 2.01 / 2.02 / 1.52

[...]
I don't think that number of cores matters a lot. Most likely every reader app uses exactly one core. And background processes shouldn't be doing very much.
Interesting.

The first question would be: which system apps did you remove?

And: you only have those few lines as "CPU usage"? My list is huge (comparatively).

That load of 2 that you are having, should represent a load that becomes a queue after the value of 4 (in our case). I am seeing values above 3 in my latest `dumpsys cpuinfo`... Even if your foreground application uses only limited itself to one core, it better not use too much of that residual core. But what I am after is not data crunching from the tablet, but responsiveness.

As a matter of fact, the "idle" percentages of `top` are more reassuring (and I cannot match them with the load values) - but I see some misbehaviour.

Now if I can interest you on this:
if you tried an iterated command such as
Code:
i=0 ; while [ $(($i)) -le 100 ] ; do  date ; top -n 1 -m 1 -d 5 ; done
, you could use it on a `adb shell` and to my experience it would run as expected;
but if you used it on the tablet itself, in a terminal, if would after a while show huge delays, that are broken by some random interrupt or by you tapping on the screen:

Code:
05:49 --> Start. A series of 5s delayed blocks are printed after this 
05:54
05:59
06:04
06:09
...	-> all 5s delays
07:06
07:11
07:16
08:19 --> start of much longer delays
09:22 --> awaken by touch
09:29 --> now closer
10:33 --> now longer...
10:38
11:41
12:44
13:48
13:53
14:24 --> awaken after auto screen lock
14:29
14:36
15:40
16:19 --> awaken by touch
16:24 --> now closer
17:27 --> now longer...
One of the problems I am experiencing is: the device seems to fall asleep like a narcoleptic. When you are "flipping pages" interleaving long breaks, you may not notice it, but if you are using an interactive application - such as, you are typing on a BlueTooth keyboard - after a little while you can bang all you want on the keyboard but the screen will remain frozen. Touch on the screen, and your past bangs will be rendered in a burst.

I need the device to work on interactive applications: I need the way and the option to inhibit that it falls asleep.
mdp is offline   Reply With Quote