Linked by Hadrien Grasland on Fri 15th Apr 2011 10:24 UTC
OSNews, Generic OSes Ever since iPhoneOS (now iOS) has been released, there's an old fight going on about how multitasking should work on personal computers, and more specially what should happen to applications which are put in the background. Some advocate that they should be dipped in virtual liquid nitrogen and stop doing anything, like on iOS, which others advocate that they should continue to run in the background, like on desktop OSs. What about putting a little more flexibility in there?
Thread beginning with comment 470263
To view parent comment, click here.
To read all comments associated with this story, please click here.
Neolander
Member since:
2010-03-08

I think it has something to do with network utilization and people who never shut apps down. In defense of the latter, some multitasking implementations, textbook example being iOS', really push this bad practice forward.

Many networked services require regular polling in order to check that the device/app is still connected. Which means that the network chip is regularly needed. If the power management daemon turns the network chip off after an amount of time x, and the polling interval is y, then if y < x what you get is a network chip that's permanently on... And that hurts battery a lot.

Also, there's the issue of poorly coded apps which are polling-based instead of being event-driven. There are some people who still code event loops this way...

Edited 2011-04-16 08:51 UTC

Reply Parent Score: 1

Alfman Member since:
2011-01-28

Neolander,
"Many networked services require regular polling in order to check that the device/app is still connected."

I'm not too familiar with what the SDKs look like on these platforms, so maybe they are drastically different than PC operating systems. But generally speaking a TCP service can just set keepalive and let the operating system handle it. There's no need to wake up the idle process at all.

UDP is a different beast since the application has to handle the packets, but even so it shouldn't need to wake up more than a few milliseconds per few minutes to handle keepalives. Even the standard SIP VOIP protocol is typically configured with a re-registration period of a few minutes if not longer.


This obviously isn't to say that all background applications are written efficiently.
I was curious about skype, so I did a wire trace on the desktop version. It appears to send some sort of keepalive with 15 practically empty packets every 100s for the main connection. Admitted that's a little poor, 2 packets ought to be sufficient when there are no events to communicate. Still, 15 is nothing to cry about, and the mobile version may be better.

One thing about skype in particular is that they are notoriously known for their deliberate obfuscation to protect their code, which has been shown to cause considerable CPU overhead compared to other technologies (even with encryption). I don't know if they were just as paranoid with their mobile versions?

Never the less, leaving skype in the background while idle shouldn't use any noticeable amount of battery unless it is poorly written.

"Which means that the network chip is regularly needed."

Keep in mind that if the foreground application needs Wifi/GSM to be enabled because it is doing something online, then there is no additional cost for letting the background application idly listen for packets. When the radio is on, it's on, it doesn't use more power simply because the OS has more sockets open. Unless the sockets are actually in use, the cost is exactly zero.



"If the power management daemon turns the network chip off after an amount of time x, and the polling interval is y, then if y < x what you get is a network chip that's permanently on... And that hurts battery a lot."


Well yes, this is true. But it's not like your phone's GSM radio can ever stop listening since it needs to be prepared to answer phone calls. To say that the radio wastes energy because of a background app which could potentially receive traffic is a little meaningless.

With WiFi/802.11 things may be a little different, but I see no reason it couldn't be explicitly shut down when it's not needed by the primary task. Ideally this would be a natural use of multi-homing. The caveat here being how are existing connections migrated between GSM and Wifi transpearently? TCP does not support this, SCTP does, but is not common. UDP support for multi-homing would need to be built into the applications.

Without breaking compatibility, the best option available for transparent switch over would probably be to run application traffic over a VPN protocol (encrypted or not) which supports multihoming. This way the carrier can dynamically route all traffic via either GSM or Wifi as needed.

Reply Parent Score: 1