Reply
Thread Tools
Posts: 2,076 | Thanked: 3,268 times | Joined on Feb 2011
#41
Originally Posted by qwazix View Post
that issue is completely unrelated, I didn't mean to present it as a sideffect. It had happened to me once again days before I started playing with standbydedness.

BTW battery life is not bad here, sim inserted, 3G always on, gtalk connected, light usage (most of the day near wifi, one or two short calls, around 15 minutes of 3G browsing, no wifi browsing today), suspend-policy early and after 12h I'm still at 68%
100% with this. Early is pretty much the same as suspend disabled in terms of battery life (no sim card here, 3-4 days reliable uptime, with LTE will have more realistic stats). I am still hunting for this 2 second active vs 5 second idle/dead situation, but cannot reproduce reliably. Disabling suspend definitely puts us in maemo version of multitasking etc, if we can milk even more from it with better battery life, bring it on.
 

The Following 2 Users Say Thank You to szopin For This Useful Post:
kimmoli's Avatar
Posts: 562 | Thanked: 2,744 times | Joined on Dec 2013 @ Espoo, Finland
#42
Originally Posted by javispedro View Post
Do you mean when using a ssh _client_ on the phone?
no. Connecting to the phone's ssh server.

Originally Posted by javispedro View Post
Otherwise it would be weird -- because by changing ClientAliveInterval on the phone it is actually the phone the one that should be sending ClientAlive messages. But the phone is suspended!
YES. And it seems that sshd has such priorities (tjsp) in this case that it can wake up from the suspend to send the packet. OR more likely, phone does not yet suspend in 15 seconds, and this keeps it alive.

I made simple daemon which logs timestamp to a file and sleeps 10 seconds. When i have ssh open (from my pc to the phone) it does not miss a single entry.
If if disconnect ssh, it will start extending the 10 sec sleep to like 5 minutes.
Just to be sure, i commented ClentAliveInterval and restart sshd, ssh connection comes non-responsive and timestamps are not appearing every 10sec even when the ssh is open.

(note: waving your hand over the proximity sensor wakes the phone)
 

The Following 2 Users Say Thank You to kimmoli For This Useful Post:
qwazix's Avatar
Moderator | Posts: 2,622 | Thanked: 5,447 times | Joined on Jan 2010
#43
having the proximity sensor covered disables double-tap to unlock, so that is probably why it is waking the phone
__________________
Proud coding competition 2012 winner: ρcam
My other apps: speedcrunch N9 N900 Jolla –– contactlaunch –– timenow

Nemo UX blog: Grog
My website: qwazix.com
My job: oob
 
javispedro's Avatar
Posts: 2,355 | Thanked: 5,249 times | Joined on Jan 2009 @ Barcelona
#44
Originally Posted by kimmoli View Post
YES. And it seems that sshd has such priorities (tjsp) in this case that it can wake up from the suspend to send the packet. OR more likely, phone does not yet suspend in 15 seconds, and this keeps it alive.
Actually, I tried when you suggested it and was not able to reproduce, which only confirmed my disbelief. It does not wake at all after 15 seconds, does not send any traffic. Which is what I'd expect considering the behavior with other daemons.
It does not terminate the connection when I wake it up manually but I presume that's because sshd is using a monotonic clock (which does not advance while suspended). Effectively, not only is the SbJ not waking up, but when it eventually does (e.g. because of power btn or network traffic) for the sshd daemon only a second or two will have passed, so it won't send the keep alive.

The attached screenshot shows a capture of the traffic generated with ClientAliveInterval = 5, ClientAliveCountMax = 3. .1.13 is the Sbj while .1.3 is a workstation. It sends the first few keepalives correctly (every 5 seconds) until screen blanks, and it immediately suspends, missing the keep alive at t=15. At that point, things go random/downhill. It spent more than 5 minutes with no traffic at all after t=192 (I had to stop capturing).

I suggest you verify with a network sniffer to check what is going on.

Note that you can simulate a similar behavior to what you want by manually patching the SSH server to use wakelocks (this is similar to what several Android forks do). But the builtin SSHD does certainly not do this.
(And besides, that is still problematic as the moment you logout everything you were doing stops).
Attached Images
 

Last edited by javispedro; 2014-01-05 at 13:02.
 

The Following 4 Users Say Thank You to javispedro For This Useful Post:
javispedro's Avatar
Posts: 2,355 | Thanked: 5,249 times | Joined on Jan 2009 @ Barcelona
#45
Originally Posted by qwazix View Post
having the proximity sensor covered disables double-tap to unlock, so that is probably why it is waking the phone
AIUI, Android has a "hack" where hardware events will wake the phone for a few seconds, "hoping" that is enough time for the corresponding process to catch the event and decide whether it wants to keep the phone awake or not.

If the process (e.g. Skype answering to TCP traffic) does not have enough time, the phone may very well suspend while Skype is still trying to show its UI, missing the incoming call altogether.

(Sounds terribly racy to me, but I suppose that with a big enough timeout chances for a race condition are minor. Yet another reason Android's power management _sucks_).
 

The Following 10 Users Say Thank You to javispedro For This Useful Post:
Posts: 6 | Thanked: 2 times | Joined on Jul 2012
#46
Originally Posted by rainisto View Post
Not that easy, you cant say what process needs to be kept alive, you need to integrate that into each application itself.

libiphb is mostly used by alarm application which needs to wake up from suspend, and some internal apps that needs to wake up peridically.
I just been hit by this with my very simple Kitchen Timer app.

Does that mean I will have to include the entire source tree of libiphb in my project because it's not white-listed in harbour?
 
javispedro's Avatar
Posts: 2,355 | Thanked: 5,249 times | Joined on Jan 2009 @ Barcelona
#47
Another piece of data is that setting mce's policy to early seems to just keep the "mce_display_on" wakelock on even if the display is not on. That is the reason it feels the same as just raising a wakelock, because that's what it seems to be
 

The Following 2 Users Say Thank You to javispedro For This Useful Post:
javispedro's Avatar
Posts: 2,355 | Thanked: 5,249 times | Joined on Jan 2009 @ Barcelona
#48
Originally Posted by tanghus View Post
I just been hit by this with my very simple Kitchen Timer app.

Does that mean I will have to include the entire source tree of libiphb in my project because it's not white-listed in harbour?
Did you look at timed or similar daemons? Though I'm not sure if they're allowed on Harbour either.
 

The Following 2 Users Say Thank You to javispedro For This Useful Post:
Posts: 6 | Thanked: 2 times | Joined on Jul 2012
#49
Originally Posted by javispedro View Post
Did you look at timed or similar daemons? Though I'm not sure if they're allowed on Harbour either.
Not really, couldn't really grasp how to use timed.

I tried to dynamically link to libiphb and submitted it to Harbour. Lets see what happens

At least my app works now, and doesn't do too many wakeups.
 
Posts: 6 | Thanked: 2 times | Joined on Jul 2012
#50
Originally Posted by tanghus View Post
I tried to dynamically link to libiphb and submitted it to Harbour. Lets see what happens
It didn't get accepted to Harbour of course, so I made a QML plugin/component including the libiphb sources which was accepted.
It should be quite easy to use in any app if any ones interested: https://github.com/tanghus/kitchen-t.../src/insomniac
 
Reply

Thread Tools

 
Forum Jump


All times are GMT. The time now is 06:21.