Reply
Thread Tools
Community Council | Posts: 4,920 | Thanked: 12,867 times | Joined on May 2012 @ Southerrn Finland
#21
Originally Posted by javispedro View Post
Do the following:
- Unplug Jolla from USB/wall charger
- Login via USB to Jolla from PC
- Run top
- Hands away from keyboard

EXPECTED OUTCOME: Top refreshes every few seconds
ACTUAL OUTCOME: Top output does not refresh. It appears as if it hung. Pressing a key refreshes it.
Allright, just tried this, altough I did not login via USB, but via WLAN.
And lo and behold!, it works just as you describe. If I do not touch anything it will not refresh. If I touch a key, it will refresh.

Also, if I ping it from another device, it starts to refresh the top listing.


Originally Posted by javispedro View Post
This happens on every other Android device out there too. And on the HP Touchpad.

The device awakens every time there's some traffic (and keeps awake for a few seconds after that because of some Android design failure), so things like sshfs will work. But it will not wake for SIGALRMs, select() timeouts, and other common POSIXy things. It is unusable as a pocket computer.

If your device still refreshes then some other device on your network is throwing unicast traffic to your Jolla, keeping it awake. But I doubt this.
 

The Following 2 Users Say Thank You to juiceme For This Useful Post:
javispedro's Avatar
Posts: 2,355 | Thanked: 5,249 times | Joined on Jan 2009 @ Barcelona
#22
Originally Posted by juiceme View Post
Allright, just tried this, altough I did not login via USB, but via WLAN.
Yep, I meant WLAN -- fixed the post.
 

The Following User Says Thank You to javispedro For This Useful Post:
Community Council | Posts: 4,920 | Thanked: 12,867 times | Joined on May 2012 @ Southerrn Finland
#23
Originally Posted by javispedro View Post
Code:
This supposedly could help (from irc when asking if screen on could be faked):
    echo asdf > /sys/power/wake_lock
The problem with that is that wake locks are deleted when the process that created them dies. In the above command line, a subshell (or /bin/echo) is the one creating the wakelock and thus the lock dies as soon as echo dies, which is immediate.
OK, so you argue that as the wakelock taking process is gone, now the device should revert back to the non-responsive state, right?
I tried that command, logged off and logged back on, and now when I launch "top" it does refresh continiously... How is that?
 

The Following 2 Users Say Thank You to juiceme For This Useful Post:
javispedro's Avatar
Posts: 2,355 | Thanked: 5,249 times | Joined on Jan 2009 @ Barcelona
#24
Originally Posted by juiceme View Post
OK, so you argue that as the wakelock taking process is gone, now the device should revert back to the non-responsive state, right?
I tried that command, logged off and logged back on, and now when I launch "top" it does refresh continiously... How is that?
Well, no idea. I might be completely wrong.
 

The Following User Says Thank You to javispedro For This Useful Post:
Posts: 702 | Thanked: 2,059 times | Joined on Feb 2011 @ UK
#25
With just ssh in top does indeed pause for me. I'd not noticed this before. I presume it's because I usually have an sshfs running too as that's the only semi-nice way I can get to it from my Mac.
 
qwazix's Avatar
Moderator | Posts: 2,622 | Thanked: 5,447 times | Joined on Jan 2010
#26
After 8 hours off charger the SbJ is at 60% with the suspend disabled which is not bad, so I think I'll keep it like this. Definitely better than the Z10.

The only thing I miss is the double-tap to unlock, especially now that the phone wakes up instantly. Before it took a couple of seconds to wake up, to the point that I pressed a second time resulting in the phone responding to both events and waking up for a moment before sleeping again.
__________________
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
 

The Following 2 Users Say Thank You to qwazix For This Useful Post:
javispedro's Avatar
Posts: 2,355 | Thanked: 5,249 times | Joined on Jan 2009 @ Barcelona
#27
I've been reading the Android kernel source a bit (I'm an Android hater, not a hacker, and would prefer to keep it that way -- besides I feel like puking every time I read some of the hacks).

Seems that user-space wakelocks are not reclaimed when the process dies -- and thus they are prone to being leaked (a dubious decision if you ask me). But then this means that the approach in the first post is a valid way to take a permanent wake lock:
Code:
echo asdf > /sys/power/wake_lock
And indeed I've checked and it does the same my trivial module did. If you do the above command, the kernel is not suspending. You can list current wakelocks in /proc/wakelocks.

I have no idea why it doesn't work for szopin -- maybe we are talking about two different problems here? What's exactly the difference with mcetool "suspend policy"? I am quite sure that with an active wakelock it does not suspend at all.

Besides, with the wake_lock, double tap to unblock still works.


Originally Posted by aegis View Post
With just ssh in top does indeed pause for me. I'd not noticed this before.
Yeah, well. I discovered this the moment I logged in via ssh to the device. Not only it was a surprise to me: the fact that no one else mentioned this was also a surprise. Opportunistic suspending is terribly annoying if you're trying to do anything useful with the device -- background applications basically get SIGSTOP'd the moment you turn the screen off. Computations are interrupted, timeouts are ignored, and writing daemons becomes hard.

If I had known beforehand that the Jolla device used opportunistic suspending, I probably would never have bought it. I know they probably had no choice....


The good news is that I was using "permanent wake_lock" mode to workaround this and that it had 'acceptable' battery life when compared to the stock (with tohd running) software.
The bad new this is that improving the battery life when under "permanent wake_lock" mode might be very well impossible. The kernel is full of hacks (Qualcomm-made no doubt) that just assume the device is going to spent most of its time suspended. There are bazillions of sub-second timers everywhere, in the kernel, the Android side...
 

The Following 15 Users Say Thank You to javispedro For This Useful Post:
Posts: 2,076 | Thanked: 3,268 times | Joined on Feb 2011
#28
Originally Posted by javispedro View Post
I have no idea why it doesn't work for szopin -- maybe we are talking about two different problems here? What's exactly the difference with mcetool "suspend policy"? I am quite sure that with an active wakelock it does not suspend at all.
Never said it doesn't, just thought I'd mention it as had to run and my question on IRC had no other answers at this point.


Besides, with the wake_lock, double tap to unblock still works.
Interesting, need to compare battery consumption in both cases, though expecting the same, btw when Jolla is acting as a hotspot (without sim, just for ssh) I have no problems connecting to it after some time (whether new connection or resuming old), but battery consumption is even worse than suspend and on router.

The good news is that I was using "permanent wake_lock" mode to workaround this and that it had 'acceptable' battery life when compared to the stock (with tohd running) software.
The bad new this is that improving the battery life when under "permanent wake_lock" mode might be very well impossible. The kernel is full of hacks (Qualcomm-made no doubt) that just assume the device is going to spent most of its time suspended. There are bazillions of sub-second timers everywhere, in the kernel, the Android side...
Can you share your workaround, want to see which way is best to have (and the least battery hungry)
 
javispedro's Avatar
Posts: 2,355 | Thanked: 5,249 times | Joined on Jan 2009 @ Barcelona
#29
Originally Posted by szopin View Post
Never said it doesn't, just thought I'd mention it as had to run and my question on IRC had no other answers at this point.
Ah, I see. Well, echo asdf > /sys/power/wake_lock is basically "my" workaround too. I was just too stupid to figure out that there was a way to create these wakelocks from userspace. From what I see, a userspace space wakelock should be the same as a kernel one (except the type is forced to WAKE_LOCK_SUSPEND but this is what we want...).

---------

So, I've found the difference.

Seems that Android has a middle state between suspend and normal that is called "early-suspend". "Double tap to unlock" seems to be enabled during early-suspend, and thus will only work when the device is either suspend or "early-suspended".

Having a wakelock prevents the device from suspending when the screen is off, but it will not prevent it from going to early-suspend, it seems. So double tap to unlock works and I presume some peripherals are put in a low power mode (dynpm on Android is basically non-existant it seems).

Using mcetool --set-suspend-policy=disabled disables BOTH suspending and early-suspend altogether. Therefore, double tap to unlock does not work. However, there is a third method, mcetool --set-suspend-policy=early, which enables early-suspend only. I suspect this third method will be exactly the same as taking a wakelock.
 

The Following 8 Users Say Thank You to javispedro For This Useful Post:
qwazix's Avatar
Moderator | Posts: 2,622 | Thanked: 5,447 times | Joined on Jan 2010
#30
Tomorrow's question, does the SbJ have better battery life with --set-suspend-policy=early?

So far I'm pretty much happy that it made it for 14 hours with 15% remaining with suspend completely disabled.
__________________
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
 
Reply

Thread Tools

 
Forum Jump


All times are GMT. The time now is 10:54.