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 470261
To read all comments associated with this story, please click here.
Multitasking <> Inefficient CPU utilization
by Alfman on Sat 16th Apr 2011 08:30 UTC
Member since:

Can someone explain to me why people believe that multitasking is inherently causing so much excess battery drain?

Sure, background apps _can_ drain the batter, but there's absolutely no reason they need to. Even with a persistent idle connection.

As long as they are event oriented or blocked, then the operating system will never wake them up until data is ready. So the VOIP client in the background should register at 0% cpu when connected but idle.

It sounds many of the posts are arguing that running two or three (active) tasks simultaneously consumes more battery current. While inherently true at any moment in time, it's not clear to me that the total battery draw after performing all three tasks in parallel is any worse than in series.

Keep in mind that CPUs are most efficient at full utilization. In other words, running the cpu at 100% for one minute is more efficient than running the cpu at 10% for ten minutes. Which, in turn, is more efficient than 1% for 100 minutes, etc.

Also, in series, the screen/wifi might need to be powered 3x as long than if the tasks could be done in parallel.

Reply Score: 3

Neolander Member since:

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:

"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