← previous next →
Pages: 1 [2]

Author Topic: 2% power drain per hour on a sleeping device is not acceptable  (Read 7750 times)

Adam Boardman

  • Full Member
  • ***
  • Posts: 191
    • View Profile
2% power drain per hour on a sleeping device is not acceptable
« Reply #15 on: June 30, 2018, 09:29:53 am »
Interesting work, I look forward to seeing the final result.

One of the aims of the gemian-lock is to eat key presses that happen when the device is closed due to the fact that the device squashes its keyboard. These are of course more likely when the device is on, but as the esc key is an 'on' key that can happen whilst its closed, or if a call comes in etc.

My thoughts were that those that don't want to be typing their password all the time would add a config setting to turn on/off the password feature within gemian-lock whilst still keeping its other purposes (eg stray key eating, call answering, voice assistant - currently simulated with 'saytime' until such features are added).

For the no-password mode the lock screen would then only unlock on key-presses when the device is open.

In my initial testing I found that closing the device slowly with a terminal open would give me a few lines of key-presses sometimes but also other times it would give me no key-presses. Testing was done with the initial x25 keyboard mat.
Logged

Eric BF

  • Jr. Member
  • **
  • Posts: 89
    • View Profile
2% power drain per hour on a sleeping device is not acceptable
« Reply #16 on: June 30, 2018, 10:06:49 am »
What did I do? Not much really. I think the main thing I did was turn the screensaver off in the lxqt session management section. To get the 0.3% ph drain, I obviously have wifi and bluetooth turned off. But I cannot think of anything else I may have done. If I think of anything else (I have played around with quite a few things this week including different window managers etc.), I will post here.
Logged
Gemini 4G Debian
OpenPandora with Debian

psionlover

  • Newbie
  • *
  • Posts: 34
    • View Profile
2% power drain per hour on a sleeping device is not acceptable
« Reply #17 on: June 30, 2018, 10:30:10 am »
Quote from: Eric BF
What did I do? Not much really. I think the main thing I did was turn the screensaver off in the lxqt session management section. To get the 0.3% ph drain, I obviously have wifi and bluetooth turned off. But I cannot think of anything else I may have done. If I think of anything else (I have played around with quite a few things this week including different window managers etc.), I will post here.
I just realized @mithrandir also has much better PM, because he has 1.2% drain ph with wifi+BT turned on. So probably my device with poor PM is the special case not yours  So I will also check again.

[Edit] I checked two times (unhook device from usb, wifi/BT off, suspend) and both times I had roughly 2% drain ph. No clue why, but if I have more info I will update
« Last Edit: July 02, 2018, 10:50:50 am by psionlover »
Logged

Eric BF

  • Jr. Member
  • **
  • Posts: 89
    • View Profile
2% power drain per hour on a sleeping device is not acceptable
« Reply #18 on: June 30, 2018, 02:40:52 pm »
It will be interesting to see if there is anything special you are doing to have such significantly worse power drain.  Keep us posted!
Logged
Gemini 4G Debian
OpenPandora with Debian

mithrandir

  • Full Member
  • ***
  • Posts: 191
    • View Profile
    • http://www.mygnu.de
2% power drain per hour on a sleeping device is not acceptable
« Reply #19 on: June 30, 2018, 05:53:00 pm »
Quote from: psionlover
Quote from: Eric BF
What did I do? Not much really. I think the main thing I did was turn the screensaver off in the lxqt session management section. To get the 0.3% ph drain, I obviously have wifi and bluetooth turned off. But I cannot think of anything else I may have done. If I think of anything else (I have played around with quite a few things this week including different window managers etc.), I will post here.
I just realized @mithrandir also has much better PM, because he has 1.2% drain ph with wifi+BT turned on. So probably my device with poor PM is the special case not yours  So I will also check again.
Today it has been different. Same situation as yesterday. 12 hours without use after pulling the plug, but only 2% drain (0.17% per hour).
Logged

tuk0z

  • Newbie
  • *
  • Posts: 45
    • View Profile
2% power drain per hour on a sleeping device is not acceptable
« Reply #20 on: July 01, 2018, 07:53:56 am »
Awesome @psiolover, @Kiriririn, @Eric and other posters here
I'll be joining your efforts as soon as I can make my Gemini boots into Debian (boot #3 here, that should come out when pressing Esc+Side-key on start up)
Logged

rubus-3.142

  • Jr. Member
  • **
  • Posts: 56
    • View Profile
2% power drain per hour on a sleeping device is not acceptable
« Reply #21 on: July 01, 2018, 12:19:56 pm »
Quote from: psionlover
I tested quite a few times now, but if I leave the device in suspend mode overnight it still drains the battery with 2% / hour. I made sure that wifi and bluetooth both where off. I am very curious what other people's experiences on this are. Adam Boardman wrote anywhere that he experiences 2% drain on a full night. What can I do to achieve a better power management on my device

Sorry not knowledgeable enough to contribute ot the Linux threads, but  for interest -  over on planet android I am getting 4.5% per HOUR with the rooted image on a WiFi only device  
https://www.oesf.org/forum/index.php?showtopic=35323

From memory the stock image was a lot lot less than this
Logged

tuk0z

  • Newbie
  • *
  • Posts: 45
    • View Profile
2% power drain per hour on a sleeping device is not acceptable
« Reply #22 on: July 02, 2018, 08:25:46 am »
here are the battery stats on my Gemini with Debian TP2 and system defaults:                                                    
                                                                                 
Code: [Select]
| Action             | Test duration | % battery used | ~per hour | battery life estimation |
|--------------------|--------------:|---------------:|----------:|------------------------:|
| lxqt suspend       |         10:00 |             10 |         1 |                    100h |
| lxqt suspend       |          1:00 |              1 |         1 |                    100h |
| constant light use |          2:30 |             23 |         9 |                     11h |
After reading Rubus post above I'll have to check this on my new rooted Android.
« Last Edit: July 02, 2018, 08:45:24 am by tuk0z »
Logged

s1b1

  • Newbie
  • *
  • Posts: 5
    • View Profile
2% power drain per hour on a sleeping device is not acceptable
« Reply #23 on: July 02, 2018, 08:30:19 am »
Mine drains 50 percent in 8 hours, I haven't changed much other than formatting and "downloading" the nvram and firmware files because the terminal emulator said the host name was changed to "node-43afea90309a" or something and I couldn't connect to certain websites. I forgot it initially has a SSH server running
Logged

psionlover

  • Newbie
  • *
  • Posts: 34
    • View Profile
2% power drain per hour on a sleeping device is not acceptable
« Reply #24 on: July 02, 2018, 08:57:18 am »
Quote from: s1b1
Mine drains 50 percent in 8 hours, I haven't changed much other than formatting and "downloading" the nvram and firmware files because the terminal emulator said the host name was changed to "node-43afea90309a" or something and I couldn't connect to certain websites. I forgot it initially has a SSH server running
Thanks. Could you specify if you had wifi/BT off or not. If you did not have wifi/BT off would you please do another check with wifi/BT off ?

[update] just changed a typo
« Last Edit: July 02, 2018, 12:42:23 pm by psionlover »
Logged

s1b1

  • Newbie
  • *
  • Posts: 5
    • View Profile
2% power drain per hour on a sleeping device is not acceptable
« Reply #25 on: July 02, 2018, 09:00:04 am »
I have wifi off and disabled the bluetooth service
Logged

tuk0z

  • Newbie
  • *
  • Posts: 45
    • View Profile
2% power drain per hour on a sleeping device is not acceptable
« Reply #26 on: July 04, 2018, 06:09:54 am »
Looking at this thread we have quite different "suspend" happening here (bold and a couple links added by me).

Quote from: psionlover
Quote from: Eric BF
with wifi off, and screensaver disabled (I do not want to keep typing my password every time), my system was at 87% battery last night. Closed lid and went to sleep. Work up, opened system and battery was at 85%.
---
The system seems to simply turn off the screen as there are messages in /var/log/syslog throughout the night.  The screen reawakens immediately on opening the lid.  The battery is now 83%, 6 hours after getting up.
Same experiences here. I can also still ssh from outside to the device and do all kinds of stuff on it while the device is in 'suspend'. That is why I already asked myself is the device really suspended if I do 'suspend'. What does 'suspend' mean anyway ?

But I don't care what suspend means if I would have your version of sleep/suspend/lock on my device and have 2% drain in 6 hours I would be very satisfied. So please find out what you did to get your 0.3% drain / hour and share here

Quote from: Kiriririn
You can identify a proper suspend by some of the log info printed by the kernel in dmesg (though unmodified kernel is hilariously verbose and it's difficult to pick apart), or also by the fact that the device will be completely cool to the touch (burning 2% an hour produces faint heat)

I think I've just had a successful suspend by disabling part of the LogindSessionTracker and also adding a script to disable wifi via networkmanager before sleeping (my hacks are here), at least in terms of not losing any battery % at all over 30 mins and no increase in process CPU times from when I closed the lid
---

So something I changed has fixed it! Just left the gemini overnight with a load of applications running and it only dropped 1% and didn't freeze!
I suspect it is the logind dbus removal that did it, but that isn't a totally harmless change as I now have to restart repowerd on login. Needs more investigation...
I also removed power button/esc key handling from gemian-lock - this seems to be one of the reasons that can freeze the gemini in suspend similar to xscreensaver


Quote from: Adam Boardman
One of the aims of the gemian-lock is to eat key presses that happen when the device is closed due to the fact that the device squashes its keyboard. (...)


Quote from: s1b1
Mine drains 50 percent in 8 hours, I haven't changed much other than formatting and "downloading" the nvram and firmware files because the terminal emulator said the host name was changed to "node-43afea90309a" or something and I couldn't connect to certain websites. I forgot it initially has a SSH server running
Please check these links:
- Suspend and hibernate (Arch linux wiki)
- How to read the linux journal (systemd, Arch linux wiki)

Continuing testing on Gemini WiFi (MediateK X27) with default LxQt here, I've had both succesfull and aborted suspend happen. With respectfully:

1. Very low battery drain (<1% / hour) and log activity;
2. High battery drain (~5% / hour) and log activity.  

Am trying to check how to reproduce both cases. Will report ASAP.
I know the hardware is fine, as I can get ~0.5%/hour drain in (rooted) Android.
Logged
Pages: 1 [2]
← previous next →