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?
Multitasking is not a problem, it’s a preference. I can’t imagine not listening to music, IM, browser and some other task.
The issue is battery life. Limited multitasking which includes being able to play music in the background will save battery life for the typical user.
Actually multitasking cause a drop in productivity
But… iOS does actually multitask, and the app writer can make it run in the background. You cannot make openGL calls while runnning in the background, but that is a reasonable restriction.
For the user, doing several things at once can indeed have this effect.
However, we are talking about what the machine, not its user, is doing. There’s a difference. As an example, most mobile OSs feature a way to play a game while you’re downloading a big mail attachment in the background. How are such background processes which do not directly interact with the user until their completion reducing its productivity, if handled right ?
This isn’t what I’ve read : http://stackoverflow.com/questions/3003245/does-ios-4-make-real-mul…
Edited 2011-04-15 11:23 UTC
What if I monotask with several applications at once?
I may need to have an IM chat while looking at old emails and a spreadsheet. Is my productivity better by forcing me to go back to the home screen every friggin time and displaying only one window?
(On small screens such as the iPhone’s, ok, but on the iPad…)
Anyway, from the same author: http://theosperiment.wordpress.com/2011/04/04/touchscreens-the-most…
Gruber et al. may laugh, but the more I think about it, the more I wonder if the iPhone and iPad fad is more than a bubble… Wild expectations, meh products accepted without much criticism and everybody racing like lemmings to THE FUTURE…
You cannot state it as a simple, all-covering fact when it’s not such. For example I personally can concentrate better if I am listening to music at the same time, which obviously falls into multitasking – category.
Not surprising. Women are better at multi-tasking than men.
Meh. Would like to see if this still holds when both are raised in the same way
Don’t you mixing scheduling, task priority and grouping ?
… I thing so.
See “Completely Fair Scheduler” discussions in LKML “to give a few details”. 😉
To the best of my knowledge, scheduling is defined as the art of choosing what should be done when in situations where several processes and threads are competing for a resource. Be it disk I/O, CPU time, or whatever else one may think of.
I’ll see
Edited 2011-04-15 11:55 UTC
Do you have a link to the beginning of the discussion in the archives ?
EDIT : Oh, well, found, I think, although not on LKML http://www.kerneltrap.org/node/8059
Edited 2011-04-15 12:16 UTC
“old fight going on about how multitasking should work on personal computers”
People are calling tablets and smart phones PCs now?
Frozen tasks are not multitasking. Multitasking is multiple running programs. If they are not getting CPU time its not multitasking.
Well, for me personal computing designates all computers which are designed to be owned and operated by a single individual at once in the largest part of their life cycle.
This is also the definition of Wikipedia : http://en.wikipedia.org/wiki/Personal_computing
Well, since Apple have decided to call the iOS task switcher multitasking ( http://www.apple.com/iphone/features/multitasking.html ), we are now forced to include in multitasking the act of holding several processes in memory at once, even if they do not receive CPU time.
Edited 2011-04-15 12:07 UTC
Well, since MinTruth decided to call war peace and slavery freedom…
What iOS usually does is called task-switching, not multitasking. iOS has very limited support for multitasking, to complete a download, for example. However, if I load a computer algebra system (say) onto an iPad, I wouldn’t be able to start a long computation and let it go for a half hour while in the meantime I read email or other things. Because of this, the iPad will not substitute for a PC in its current form.
I understand that Apple imposes this limitation for reasons that are important to battery life, etc., but that doesn’t change the fact that it isn’t multitasking. Since WebOS, Windows Mobile, and now Playbook came out with real multitasking, making Apple look kind of, you know, Stone Age, Apple’s solution has been to point to a task switcher UI and say, “Look! multitasking!” No, it isn’t.
Not quite. It’s a bit more interesting. As has been mentioned multiple times, iOS 4 offers a number of hacks that allow to get around the “one task at a time” limitation for very specific purposes.
As an example, Skype for iOS works using such a hack, called “voip mode”.
The thing is, it’s not a sustainable model, because as more people figure out what they can develop, Apple will have to add more and more hacks or to ban more and more applications. But who could explain that to them ?
Edited 2011-04-15 14:28 UTC
What would make more sense, is to put the decision in the hands of the user and not just the application developer or platform designer…
For instance, i might want a complex calculation to complete, using 100% cpu and draining my battery very quickly, but i also want to read my mail or something while its doing that. Under Apple’s system i would either need to waste my time watching the progress of the cpu intensive app, or suspend that app while i read my mail.
You should have a choice between suspending an app (thus it stays running, but is frozen – effectively a SIGSTOP), killing the app or letting it run in the background (with the option to adjust its priority so its processing doesn’t interfere with my foreground app). App authors and platform vendors should only get to choose a default, not force the user.
Hum… I considered something like my phones where you have one hardware button for killing apps and another hardware button for leaving it in the background, but indeed this should be emulated in software when it’s not available.
You’re also right that the ability to override default app settings should be available for power users, at least on larger form factors. Something like unices’ nice or windows’ file properties…
Edited 2011-04-15 17:19 UTC
I know. That’s why I said usually.
Explain what to whom? Certainly Apple’s engineers are smart enough to know this. I have no doubt that, unlike the original MacOS, iOS is capable of doing real multitasking; unfortunately, it’s not allowed to do so.
Of course
No phone OS could exist without multitasking, as you need to be able to receive network events while the user is fooling around with the device anyway.
What I consider as non-sustainable is their way of saying “we support multitasking, but only through hacks for x and y” and gradually add other use cases to that list as needed. Increasing OS complexity this way is rarely a good idea.
Right, Skype works that way, as does the Cisco client for iOS. And because of that, my battery while running either one of those in the background is at 50% by noon. Right now, with otherwise same usage but no VoIP client running? 90%.
I’m not in favor of tinkering with how multitasking runs on desktop OSes, but I prefer how iOS does it at this point, for everything but VoIP. If they extended that to all apps, I’d spend most my day killing apps due to battery suckage.
I already got rid of my Android phone because its battery life was terrible. I don’t want to deal with that again. It’s a phone, and at the end of the day, I need to make phone calls.
It does become a touchier subject when you get to tablets though.
Of course they eat lots of power ! They need a network connection to be permanently on in order to work, how could it work another way ? Those applications simply cannot work without true multitasking, so it’s unfair to blame multitasking here, it’s as if you were comparing battery life when making phone calls with standby battery time and concluded that phone calls’ power consumption sucks, it’s just not right.
That being says, your “keep closing apps” nightmare does show that the way many phones manage apps is broken. The “let’s put everything in the background as a default setting” philosophy is just wrong, because it encourages wasting resources. If you don’t need an app, you should close it. If closing apps is not intuitive, it’s a design failure. Switching between opened tasks should be the exception, not the default.
Edited 2011-04-15 19:42 UTC
Yes the old debate is entering the tablets and smartphones now.
Since theses devices are becoming more and more powerful.
Whatever we thing, they will one day be as powerful than our today’s PC. And one other day they will surpass them.
And how they will schedule the tasks running on them has to be debated.
Just one thing to add, scheduling is a complex matter and on open-source OS (That I know) like FreeBSD (See KSE Project) and Linux, it has almost introduced a “war”.
And I guess with Neolander when he wrote: -“…scheduling is defined as the art of choosing what should be done…”.
Yes it is practically Art. :-))
As I said, I think that even the desktop can benefit from a more subtle approach to multitasking with at least some notions of foreground and background tasks.
Laptops could last longer if they managed tasks in a power efficient way.
You do realize that PCs will also continue to grow more powerful, and without the size and power constraints of mobile devices, they will continue to be more powerful than the equivalent mobile device. Will they pass today’s PCs? Sure, will they pass the PCs of the future? I doubt it.
The laws of physics almost guarantee it.
Have a screening or approval process for background applications.
Those apps that pass the approval process, can run in the background just like IOS system apps.
Those that don’t… can’t.
Such approval processes have a tendency not to scale very well when the platform becomes successful, among other issues (who approves ? based on which criteria ?), so I think that they should only be used in extreme situations…
Edited 2011-04-15 12:37 UTC
Apple should do the screening for IOS.
Other companies might create special white lists for different carriers.
There really aren’t that many applications that *need* to run in the background. It doesn’t need to scale to millions of apps.
The ones that do should have to go through an approval process of some kind. It’s not unheard of. MS does this with drivers with their driver certification (WHQL).
This is really the best solution as far as I’m concerned.
…although suffering from a heavy use of “which” (it is very often interchangeable with “that” so a little variety will definitely help your style).
One of your most clear writings though. I enjoyed it even though I hate touch-tech and, most of all, tablets.
Cleaned up a bit, how is it now ?
The clearer it is in my mind, the clearer it is on paper… Foreign languages are unforgiving.
The tablet is only here as a “how I came up with this” introduction. As you probably know if you’ve read last months’ posts, I’m not fond of current touchscreens and tablets either, though I don’t dislike each for the same reasons.
Tablets manage to get around the defects of touch interfaces a bit as they can make controls bigger, but the current implementation is in my opinion not what it should have been.
Edited 2011-04-15 14:11 UTC
http://developer.apple.com/technologies/ios/whats-new.html#multitas…
Go on. Build arguments.
Edited 2011-04-15 14:12 UTC
Nice to see someone explaining how a balance is needed with smartphones since battery life is limited.
A lot of people seem to think multitasking limitations in smartphones have more to do with the technical incompetence of the os developers. Full and equal multitasking is actually easier to develop than a specialized system where priority is given based on application needs.
Like it or not but most users are not running multiple applications in the background. Smartphone battery life remains a problem so as much as geeks would like a mini-desktop OS that doesn’t mean it is the best choice for the mainstream. Hopefully there will be an advancement in energy storage some point so these compromises don’t have to be made.
Which cannot handle download while playing game (while being a lot more powerful in theory).
But as we are nitpicking I consider iOS as a multitasking OS, but not a multi application one, as the limitation come primary from the user space and GUI.
I don’T know the details of Apple implementation, but choices are given and users seems to prefer the Apple approach (even the playbook with QNX have hardly convince anybody with its multi tasking abilities). The Apple implementation seems like a sensible one, as the user don’t really seem to care.
And I don’t think that normal desktop user cares at all about it, they only want their application to respond quickly if awoken and give notification in their state change. Background tasks are more like “magic elves” for the user as they give little control
( they are not directly available to the user ).
And of course as computer litteral people we care about multi tasking, because we can probably bear more than 1 “window” one our screen for our attention, and that we want to perform task to maximize the computing time of the device.
There isn’t one single answer to this because we’re not all identical. This even comes down to brain topologies – ADHD for example is a physical different in the prefrontal cortex wherein the part of the brain that in most people marshals the other parts of the brain to do things at will doesn’t really activate – like a town where the mayor is always asleep and everyone else is very busy doing what they think right. For someone like this a lot of multitasking is going to be a real problem unless you’re already a real expert in what you’re doing.
So there’s not just subjective preference, here, there’s different needs. For me OSX’s interface strikes the right balance between multitasking and alerts, though Growl, which some people swear by, isn’t all that helpful.
You can have completely different preferences in interface from me. That’s allowed.
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.
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
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.