marmistrz | # 1 | 2018-01-11, 11:16 | Report

Some time ago I heard something about iphb - that it's used to make sure that the application is woken often enough.

I remember the name libiphb from my N900 experience, so it's not a new thing. But the whole idea sounds so heretically Android-ish - suspend the app and wake it up when we think it's needed. Normal Linux distros don't seem to use such contraptions.

What I mean: if we allow the system to suspend the application on its own discretion, what we get is something like the awful Android Doze.

Did I get something wrong or are we just mimicking the Android bad design decisions?

edit/clarification: I'm only interested in native apps, not Alien Dalvik.

---

Last edited by marmistrz; 2018-01-11 at 11:52.

MartinK | # 2 | 2018-01-11, 11:42 | Report

Yep, it's the same thing as on Android (wakelocks) - when the screen of the device is turned off, the device will basically do a suspend to RAM (you can check fro that in the journal), freezing all running applications. This is a slight simplification - it looks like apps with an active network socket (jabber/IRC) might continue running or might be woken up on network traffic - anyone more knowledgeable is welcome to fill in the blanks!

Note that this only depends on screen being off - as long as the screen is on, all native apps (including the one in foreground) run at the same time (eq. apps are not suspended when in background).

This power management behavior has obvious downsides, but also makes sure it much less likely a badly written app getting stuck in an infinite cycle (or even just needless frequent polling) will drain your battery in a couple hours without you noticing, meaning the device is dead the next time you need it.

As for normal distros not needing this - well, they (quite unfortunately) don't run on any daily-useable smartphones, so they don't really have to care.

Also, there are mechanisms you can use to prevent your application from being frozen when the screen is turned off:

• there is an API to prevent suspend overall (modRana uses this when recording a tracklog)
• there is an API to schedule application wakeup at a later time (don't know the specifics, haven't used it myself)
• IIRC, there is a way to turn the suspend off, with correspondingly worse power usage

So all in all, especially as there is an API to handle these power management limitations when needed, I see this change from how N900 handled power management as rather a positive one.

---

Last edited by MartinK; 2018-01-11 at 12:01.

r0kk3rz | # 3 | 2018-01-11, 15:39 | Report

What would you propose as an alternative strategy? You want to have good battery life don't you?

To get good battery life you need to sleep as much as possible, and you can only really do that by being a little aggressive and having the system know exactly what's going on.

iphp/nemo-keepalive is a way to synchronise the wakeups on all the running apps on a system, so maybe apps want to check something on a ~30 second interval they can register such with the system and then get a kick to say 'ok do your thing and tell me when you're done' and all apps will get the same wakeup window.

You haven't really described what your issue is with the Android approach, other than use superlatives like 'heretical' and 'awful', so I can't really comment as to whether that applies to the iphb/nemo-keepalive approach or not.

freemangordon | # 4 | 2018-01-11, 17:12 | Report

@MartinK: I'd recommend having a quick look at https://github.com/community-ssu/iph...e/master/iphbd and https://github.com/community-ssu/iph.../master/iphb.c before commenting what iphbd does or does not.

However, It has NOTHING to do with wakelocks or screen being on or off. Basically, what it does is to group network activity, so radios are turned on only for a small period, not every time an application has something to send over the network. When you register with libiphb and call iphb_wait, you tell it whether to block or not. If you choose to not block, you have fd to select/poll on. All registered applications are being "informed" at the same time (by either returning from iphb_wait (if you choose blocking method), or by data available to be read from fd (for async method). That way, all applications start sending their data at the "heartbeat" moment, radios are turned on, data send and radios turned back off (as there is no more data to be send), thus saving battery life. See https://github.com/community-ssu/iph...iphbd/hbtest.c for more details on how is this API used.

Another thing iphb does is to queue keepalive packets, so they are send only when there are other types of packets to be send (IIRC, see kernel module code for what exactly it does and how).

marmistrz | # 5 | 2018-01-11, 21:26 | Report

freemangordon: Thanks for the detailed reply!
In other words, libiphb is only an optimiziation, and a application will not cease to work correctly whether it uses libiphb or not - do I understand correctly?

What is responsible for the suspending of apps? Is this the kernel?

olf | # 6 | 2018-01-11, 21:37 | Report

mcetool -sdisable

@freemangordon, presumably @MartinK just intended to describe SailfishOS' power management in general, what he achieved IMO well.

Actually your statement fits just as well to the original statement by @marmistrz:
All in all I wonder, if the original presumption made in the thread title, "Why do we have iphb in the whole Maemo family" really holds true, as @marmistrz obviously meant to include MeeGo, Mer and SailfishOS in that "family" (although the relationships are weak, e.g. between Diablo and SailfishOS), judging by his last sentence, "edit/clarification: I'm only interested in native apps, not Alien Dalvik."
Maybe the whole confusion just arises from fuzzy (i.e. imprecise) wording.

@all: Is IPhb used in Mer / SailfishOS (as I have not stumbled over anything IPhb related in SailfishOS, yet)?
@marmistrz, do you have any reference (beyond "having heard of")?

r0kk3rz | # 7 | 2018-01-12, 12:22 | Report

Yeah it is, but its only one part of the whole picture.

The main client library that apps would need to implement is nemo-keepalive which wraps various interfaces from things like iphb, mce, and dsme to handle things like background tasks and display blanking.

Apps that do not implement this may not work as expected, particularly around time sensitive things like QTimers, eg. if you set a QTimer to 30 sec intervals and didn't register it, you will find it will fire much less frequently than 30 sec when the device is suspended.

marmistrz | # 8 | 2018-01-12, 15:08 | Report

Yes, https://build.merproject.org/package...r:core/libiphb

I treat MeeGo as a more average-user-friendly continuation of Maemo and SailfishOS a continuation of MeeGo, hence, by transitivity, SailfishOS a continuation of Maemo.

This statement comes from a private message/e-mail.

A well-written application will either do the work it needs to do or wait at a blocking syscall. This means that as long as all of the applications I'm using are well-written, I don't need to suspend the applications.

A diagnostic tool to find out which applications are battery-hogs plus the possibility to force-suspend the misbehaving ones (as an opt-in; Android Doze is an per-app opt-out which is one of the reasons it's so horrible)

Agreed. Then, if the application will tolerate a ~5 seconds deviation from the sleep time, it should declare it. The system should not break the applications.

Well, the "heretical" was a little pun, coming from the Android solutions are very often disliked in the Maemo community. I do dislike them too but the heresy is just a hyperbola

The whole idea is, that just as I am the only lord, master and the emperor on my Arch laptop, I expect the same on a phone.

1. On my Linux box an app will (almost) never be killed unless the situation is critical. Usually, if I run out of RAM (i.e. all the buffers get cleared) the system goes so unresponsive that I use the magic sysrq to kill the memory hog.
I expect the same on a phone: no app killing, unless I approve.

2. On my Linux box, an app will not be suspended without my consent. If I'm compiling the kernel and turn off the screen, the device will not stop compiling the kernel because the system is too intelligent.
I expect the same on a phone.

3. The real problem comes when you decide to port a desktop app onto a phone. A correct app will suddenly stop working because the operating system is too intelligent, even if it does nothing wrong.

And there was `mcetool -searly`. This should only enable the early-suspend. Do you have any references on what that actually does?

I found this, but it's 8 years old: http://www.thinksrc.com/2010/11/20/suspend-en.html
And this post, claiming that early-suspend was removed: https://plus.google.com/111524780435...ts/RCV8EP3hFEm

rinigus | # 9 | 2018-01-12, 17:28 | Report

I think the current system is quite good, if you know how to use it. I'll address some specific points below. Please note that my response is based on what I have learned while using and monitoring the phone as well as reading some code.

In general, it assumed that all apps which require background CPU, network, or any other processing, declare it. If you want to make something while user is not interacting
with you, please state it and it will be respected. Technically, even switching on screen leads to acquisition of wakelock and releasing it when you switch it off, in accordance to your settings. Same when you start charging.

So, when you use your apps, you are the one, through these apps, that decides when and how to sleep. On my device, during a day, the device sleeps about 80% (12h average) with non-usage times leading to 95% sleep (one suspend about 1-2 minutes). As a result, we have longer battery usage.

As pointed out above and by others, you suspend whole system, not just application. Well written application takes into account that it needs to declare if it doesn't like it at this moment.

In our case, we don't have per-app suspend. You are supposed to close this app and complain/fix the issue.


Its just that the default setting is sensible for mobile device, not for the one that is plugged in. So, application has to declare if it needs to be on and the system should respect it.

Its pretty much the same. Just only imagine if your laptop could also make these short naps and it would be efficient - now we would be talking about much longer battery life

Same here. If you compile kernel, just echo to the wakelocks file and release it later (may depend on specifics of your kernel, but should be the similar technique overall).

Yes, its a problem, but an addressable one. I have ported collectd to SFOS and had to rewrite the main loop of this daemon by specifying time when it is expected to be waken up and how to handle wakeup/suspend. Turned out to be rather simple. In the end, with the porting, the main problem is actually that desktop apps are for X, not Wayland. Addressing that is much more difficult.

I hope that I didn't do any major mistakes explaining the system. If so, please correct.

olf | # 10 | 2018-01-14, 03:51 | Report

Thanks for the pointer.

[...]

mcetool -sdisabled

As of mcetool v1.90.0.1 (© 2011; per mcetool -V) on SailfishOS 2.1.3.7:
mcetool -s, --set-suspend-policy=<enabled|disabled|early|disable_on_charger>

The webpage you found, ...
... provides the best description I have read yet (while saying Goodbye to this feature), better than https://together.jolla.com/question/...#post-id-55138 and all the linked webpages there.

But by practical experience, -senabled and -searly do not differ significantly in battery runtime, if anything at all.
Also the specific AlienDalvik issue, I tested -searly for, was unaltered: "Android apps running in the background (e.g. K9-Mail, Conversations) loose their network connection permanently, after SailfishOS automatically switching from mobile network (3G) to WLAN (but not vice versa). A restart of AlienDalvik resolves this, a restart of the SailfishOS network services does not!".

AFAIU, in theory -searly should keep CPU and I/O active in its lowest power state / sleep mode, while -senabled may suspend CPU and peripherals completely (basically like a power off), only guaranteeing RAM content to be retained ("Suspend to RAM/ StR").

Well, as Jolla 1 phones run Linux 3.4.108 (specifically such an "Android kernel" as discussed in the GooglePlus article), this feature is probably also not present in the SailfishOS kernel.
Still I wonder, if it causes any difference in the Power Management framework?

One may try to observe suspend actions statistically via mcetool --get-suspend-stats (with a rather slim output IMO and unfortunately -v does not seem to make a difference).

---

Last edited by olf; 2018-01-14 at 04:33.