Push email battery drain - Myth?

[cgray24]

I was having serious power problems lately barely getting in a days worth before having to rechange and thats with very modest actual usage.

So I decided to start daily testing of best performance. Starting with everything off and slowly adding services each day and judging the difference. Turns out having wifi off all the time saved me hours of battery life. I ended up with Push turned back on (one an exchange account) and fetch (for the other three email accounts) to every 15 mins and am very happy with the battery life now. Probaly could go two days before recharging now.



Just annoying turning on wifi when i get home everyday, wish there was a shortcut.

 

[Hutch1]

How about this... If im out and I get a new contact and put it in my phone. After that, I turn push ON for a minute to let it push my new contact to the cloud, then turn it back off. Will it work that way?

Yes bet what your actually doing is Fetch manully so why not just set it that way.

 

[ubersalad]

haha, settle down? Man I'm just trying to tell ya the guy you're paraphrasing may be wrong. No all caps or flames from me, homes.

But still ... do a full day with Push/off and Fetch/15. Then do a full day of Push/On and Fetch/Off. Maybe you'll see what I've seen .....

You are pretty serious about this that's all, the whole thing about "I am absolutely right, you are absolutely wrong".

Anyhow, I have tested it obviously, and I agree push does drain the battery. Perhaps you receive only a few emails a day, whereas I get hundreds of emails.

 

[cellocello]

You are pretty serious about this that's all, the whole thing about "I am absolutely right, you are absolutely wrong".

Anyhow, I have tested it obviously, and I agree push does drain the battery. Perhaps you receive only a few emails a day, whereas I get hundreds of emails.

::shrug::

Guess so.

 

[VTMac]

There is no one size fits all answer to whether "push" or "pull" will save battery. Let's start with an explanation of how ActiveSync and Mobileme "push" actually work.

Both make a call to the server essentially saying "I'm ready for mail for this person". But instead of returning immediately, the server just keeps the connection open. The client (iPhone) and server are both just waiting in the state until one of 2 things happen. Either the server gets mail and completes the response to the client by delivering mail, or the server times out. When the server times out, it responds to the client saying "didn't get any mail, ask again." The client will then immediately initiate a new request and the process repeats itself. This is how it works. If you don't believe it, I direct you to msdn.microsoft.com to check out all the technical details on implementing Exchange Active Sync clients.

So "push" is actually a form of pull on the iPhone (and any Exchange Active Sync based phone for that matter.)

Now, to the question of battery life. If you get lots of mail in a day, let's say on average about 1 email every 5 minutes for a total of (12 mails/hr * 12 hours), that means your doing the equivalent of a "pull" every 5 minutes or about 144 pulls in a 12 hour period. This obviously is much more activity than pulling mail every 15 minutes. Accordingly battery life will be worse in this scenario with push mail. Now if you recieved the exact same number of mails, but the mails all came in at once and were delivered in 1 request, the hit on battery life would be much lower.

In general though, using a less frequent pull interval (say 1 hour) will result in better battery life than push, regardless of the rate and amount of mail recieved. This is because generally the server timeouts are configured for something on the order of 10-30 minutes for this type of "push".

Now if you only get 10-20 emails a day and you are comparing "push" to pull every 15 minutes, you'll likely not seem a significant difference in battery life.

So why doesn't "push" actually have the server contact the phone directly. In a word - patents. RIM (Blackberry) have patents on that mode of "real" push. Hence their push is the best/most efficient solution on the market.

 

[spartanrob]

Here is my experience.
with firmware 2.0:
I have Exchange Push set up for work and a Gmail account.
Push on and Fetch set to 1 hour, my usage and standby time were exactly the same and i would get 6 hours at most with moderate use

With Push off and fetch set to 15 minutes my batter lasts for days and my usage/standby times are dramatically different.

Ever since i updated to 2.01 and Jailbroke my phone, i can turn push on and my usage/standby times are much different but the battery is not as good as with push off. But, much better than before the update. I'm going to run the same test next week now that i'm jailbroken on 2.01.

so for me, on firmware 2.0, push was absolutely a problem (btw, 3g or EDGE, it didn't make a difference, i'm on 3g 90% of the time)

 

[cellocello]

There is no one size fits all answer to whether "push" or "pull" will save battery. Let's start with an explanation of how ActiveSync and Mobileme "push" actually work.

Both make a call to the server essentially saying "I'm ready for mail for this person". But instead of returning immediately, the server just keeps the connection open. The client (iPhone) and server are both just waiting in the state until one of 2 things happen. Either the server gets mail and completes the response to the client by delivering mail, or the server times out. When the server times out, it responds to the client saying "didn't get any mail, ask again." The client will then immediately initiate a new request and the process repeats itself. This is how it works. If you don't believe it, I direct you to msdn.microsoft.com to check out all the technical details on implementing Exchange Active Sync clients.

So "push" is actually a form of pull on the iPhone (and any Exchange Active Sync based phone for that matter.)

Now, to the question of battery life. If you get lots of mail in a day, let's say on average about 1 email every 5 minutes for a total of (12 mails/hr * 12 hours), that means your doing the equivalent of a "pull" every 5 minutes or about 144 pulls in a 12 hour period. This obviously is much more activity than pulling mail every 15 minutes. Accordingly battery life will be worse in this scenario with push mail. Now if you recieved the exact same number of mails, but the mails all came in at once and were delivered in 1 request, the hit on battery life would be much lower.

In general though, using a less frequent pull interval (say 1 hour) will result in better battery life than push, regardless of the rate and amount of mail recieved. This is because generally the server timeouts are configured for something on the order of 10-30 minutes for this type of "push".

Now if you only get 10-20 emails a day and you are comparing "push" to pull every 15 minutes, you'll likely not seem a significant difference in battery life.

So why doesn't "push" actually have the server contact the phone directly. In a word - patents. RIM (Blackberry) have patents on that mode of "real" push. Hence their push is the best/most efficient solution on the market.

That's a great post .. I wish I could "digg" it up or something.

So how is this new stuff coming in September going to work? IM (MSN, etc.) conversations won't be very "real-time" if Apple isn't allowed to push messages out to the phone in real-time. Any thoughts?

 

[VTMac]

That's a great post .. I wish I could "digg" it up or something.

So how is this new stuff coming in September going to work? IM (MSN, etc.) conversations won't be very "real-time" if Apple isn't allowed to push messages out to the phone in real-time. Any thoughts?

The new notification service from Apple will only be utilized while the application in question is not running. (ie. not the foreground application). So in the case of an IM client, while you are actively using the IM client, the notification service will not be used. But when your using another application, say the iPod, one of the last things the IM client will do is ask the apple notification service to notify it when there are messages. Every application needing background notifications will do the same. The advantage of this approach over true background apps is that instead of having N applications making and receiving requests, they can all ride on the same "long pull" (as described above). This is much more efficient then each application making their own calls. But that is the key point. It is more efficient than apps each making their own calls, but it is not more efficient than NO background notifications. So yes, this will definitely reduce battery life. It will just reduce it less than if the apps had all been running in the background.

Now the downside is that it's really a "near-time" notification system. It will be fine (my guess is less than 5 sec) for things like IM clients. But lets say you had a stock application that was going to capture real time stock data and perform some sort of analysis. This isn't going to work with this notification system. Anything that truly requires "real-time" background notification (less then .5 sec) isn't going to be covered adequately by this system.

My guess is the there will be much rejoicing when the notification system goes live (because it will work) followed by much pissing & moaning when people realize this is yet another battery drain. While email does not "have" to be instant. Instant Message kinda does. So turning it "off" isn't an option to save battery as with email. So I suspect their will be even greater pressure on battery life.

I'd buy stock in 3rd party iPhone chargers ... lol.

 

[cellocello]

So, the notification system will use the same faux-push that's currently in use? And it'll try to batch things together?

Man, multiple IM convo's could become a giant drain if that's the case...

 

[kdarling]

Whether or not Push uses up a lot of battery, depends to a great extent upon the network path, some links of which I'll show below. (I've left out NATs, proxies, caches, etc.)

phone <-> Tower <-> Switching Centers <-> Internet <-> Firewall <-> Server

Exchange and IMAP Push depend on EVERY link in the path keeping the connection open.

To open the path, the phone pings the server. Among other things related to IP connections and SSL, this gives the server the phone's IP address, necessary for a reply.

If EVERY link in the path kept the connection open FOREVER, then Push would only have to ping the server once... then wait as long as it takes for a notification (server reply).

But in real life (at least for now), some link in the chain will (to conserve resources) drop its piece of the connection. Some might wait thirty minutes before dropping. But more often, one will give up in ten minutes or even less.

So whatever the shortest time is before a link in the network path stops working, is how often the phone must ping the server to keep the Push reply connection open.

Depending on where you are, and what you're connecting to, that could indeed be 20-30 minutes, and you'll get good battery life, obviously better than 15 minute Fetches.

For other locations, that could be 5-10 minutes, and you'll get horrible battery life on Push.

This is why different people get different results at different places.

 

[alFR]

If anyone wants to know a bit more about how the push system works (in fairly easy-to-understand terms) there's a series of articles here.