[Raestloz]

'm using 3 email accounts: Gmail, FastMail and My Opera mail. All three works fine on IMAP and I checked "use push if supported" and they indeed have push. Question is, can I set the sync interval to Manual and be fine? Will my battery drain faster if I use this push?

[Omnitech]

'm using 3 email accounts: Gmail, FastMail and My Opera mail. All three works fine on IMAP and I checked "use push if supported" and they indeed have push. Question is, can I set the sync interval to Manual and be fine? Will my battery drain faster if I use this push?

Enabling push on a lot of email accounts will certainly have some impact on battery life, but there are some variables there depending on what protocol you are using and how many email folders you are syncing.

If you don't care about ultra-fast email notifications, then by all means disable push and increase your sync timeframe or polling interval to some high level or manual if you like. Whether the battery-life savings will be extremely noticeable or not, once again, depends on a lot of variables. But if you don't need the fast notifications, if I were in your shoes I'd certainly turn them off.

[Marc_Paradise]

Has push changed in meaning?

Because typically it means that the device is notified of incoming messages without having to poll the remote server at all. This saves battery, while polling (imap) would cost it

Yet consensus seems to be that "push" is now more expensive in terms of battery. Has the meaning of push changed?

[eve6er69]

Has push changed in meaning?

Because typically it means that the device is notified of incoming messages without having to poll the remote server at all. This saves battery, while polling (imap) would cost it

Yet consensus seems to be that "push" is now more expensive in terms of battery. Has the meaning of push changed?

Bb10 doesn't really rely on the noc. The noc did all the retrieving and pushing to the phone with minimal battery drain. Now with the BIS not being required on bb10 devices they push or retrieve emails the same was an iphone or android phone would get them rather than a remote server checking every second and then pushing the email to your pin.

Sent from my game boy color

[Omnitech]

Has push changed in meaning?

Because typically it means that the device is notified of incoming messages without having to poll the remote server at all. This saves battery, while polling (imap) would cost it

Yet consensus seems to be that "push" is now more expensive in terms of battery. Has the meaning of push changed?

You have to know what push "was" to know if the meaning has changed.

IMAP does not have to "poll" for new messages. Please lookup the IMAP IDLE RFC.

Neither was legacy POP3 via BIS technically "push" either, though it was certainly better than POP3 without BIS, usually.

A properly working IMAP or EAS email account on a BB10 device will deliver messages much faster than BIS/POP3. BIS/POP3, if we're only talking about the notifications part, is more battery-efficient. Then again, batteries on smartphones today are a lot bigger too.

Anyway, we're off-topic, the OP's question has already been answered.

[Marc_Paradise]

[QUOTE=Omnitech;8182711]You have to know what push "was" to know if the meaning has changed.

IMAP does not have to "poll" for new messages. Please lookup the IMAP IDLE RFC.
[QUOTE]

I am familiar with it - multiple open sockets (one to each server) aren't cheap when you're connected over a cellular radio...

And even IDLE should be "Polling" every 20 something minutes by terminating and re requesting.

[Omnitech]

I am familiar with it - multiple open sockets (one to each server) aren't cheap when you're connected over a cellular radio...

And even IDLE should be "Polling" every 20 something minutes by terminating and re requesting.

It's WAY cheaper than doing constant logins like POP3 has to do. And WAY faster.

But if you want the most efficient protocol, EAS is better. Then again, there are modern extensions to IMAP that are designed expressly to make it more efficient on mobile devices by pipelining commands and so on.

TRUE push requires an out-of-band signaling method. There have been several different systems used for that. Some used SMS messages. BIS is technically push on the device-link but in terms of overall efficiency it's not because it's brute-forcing the POP server from RIM's network by banging on it constantly. Thus it's no surprise RIM/Blackberry got tired of operating that giant monster. (For that reason and many others)

Apple has their own proprietary "push" notification system, but it's just like IMAP or EAS: opens a long-lived TCP socket and sits there. Nothing else they can do really, if their only data link is the internet connection.

[dejongj]

I've put all my imap accounts to manual sync and enabled push. Having both switched on is unnecessary.

Posted via CB10

[polytan02]

The activesync outlook server at work is sh*t... apparently, since I switched from my 9800 (using BES5) to the Z10 (using AS) it creates around 60,000 lines of log a day.

I doubt this improves battery life . I have been asked to switched to 15min checks, at least up to the time we have BES10 installed. Hard to tell if battery is better or worst so far.

The only good point is that it is doing the same drap on the iPhones connected to the server so it doesn't seem to be a BB10 issue...

Posted via CB10

[Omnitech]

The activesync outlook server at work is sh*t... apparently, since I switched from my 9800 (using BES5) to the Z10 (using AS) it creates around 60,000 lines of log a day.

I doubt this improves battery life . I have been asked to switched to 15min checks, at least up to the time we have BES10 installed. Hard to tell if battery is better or worst so far.

The only good point is that it is doing the same drap on the iPhones connected to the server so it doesn't seem to be a BB10 issue...

Actually the "excessive log file generation" thing was a known and much-discussed bug on iOS devices about 1-2 months ago - perhaps you have a different "excessive log file generation" issue:

Rapid growth in transaction logs, CPU use, and memory consumption in Exchange Server 2010 when a user syncs a mailbox by using an iOS 6.1 or 6.1.1-based device

Weird that you're seeing that on the Z10 as well.

I don't understand the "switched to 15 min checks" thing. 15 min is the minimum on the Z10. You mean turn off "Push if available"?

[Raestloz]

Weird, I put my email accounts to 24 hours interval, turned off push, and when I send an email from my My Opera to Gmail, it arrives in the same minute, on 2G. Not instantly, but isn't it 'push'?

Posted via CB10

[Omnitech]

Weird, I put my email accounts to 24 hours interval, turned off push, and when I send an email from my My Opera to Gmail, it arrives in the same minute, on 2G. Not instantly, but isn't it 'push'?

The strict definition of "push" may or may not have any direct bearing on whether you get your email notifications shortly after the message arrives.

What exactly are you trying to ask?

[dataiv]

With push enabled on my phone with my imap server the phone stays connected for hours on end with the same socket. I checked last night and it was more than 16 hours with the same connection.

Despite also having the sync setting set to 15 minutes, the phone does not actually make a new connection at all during that whole 16 hour time frame.

It's been using the same connection all along with imap idle and is not wasting battery or data making extra connections. Also, I do not believe keeping that socket open is expensive at all from a battery or data standpoint. I've been watching the socket using tcpdukp on the server and there is effectively zero traffic until a message arrives, then a packet goes to the phone from the server notifying it of a change in the mail box, at which point the phone retrieves it. It seems to be pretty slick.

Posted via CB10

[Omnitech]

With push enabled on my phone with my imap server the phone stays connected for hours on end with the same socket. I checked last night and it was more than 16 hours with the same connection.

Despite also having the sync setting set to 15 minutes, the phone does not actually make a new connection at all during that whole 16 hour time frame.

It's been using the same connection all along with imap idle and is not wasting battery or data making extra connections. Also, I do not believe keeping that socket open is expensive at all from a battery or data standpoint. I've been watching the socket using tcpdukp on the server and there is effectively zero traffic until a message arrives, then a packet goes to the phone from the server notifying it of a change in the mail box, at which point the phone retrieves it. It seems to be pretty slick.

Very interesting. Because the IMAP IDLE RFC itself suggests clients close and restablish the connection at minimum every 29 minutes.

I had thought the RFC also specified a maximum open time of around an hour, but I'm not seeing that in the RFC now.

RFC 2177 - IMAP4 IDLE command

IMAP only specifies that any server inactivity timeout be no less than 30 minutes.

RFC 3501 - INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1

Interesting interesting.

[Omnitech]

Well obviously if the server implementation has a 30 minute inactivity timeout (allowed by the standard), then if the client does not close/reopen the session within that timeframe (thus the 29-minute recommendation), the risk is that the server will close the connection and logout the client.

There are a number of updates to RFC3501, perhaps some of those modified some of those recommendations. Haven't slogged through all of 'em yet.

[dataiv]

I would have thought the connection would need to ne reestablished only if it times out. However I would also suspect that if a keep alive or noop packet is sent then the connection can stay open. I see the same behaviour with Thunderbird using IMAP on the same server. No issue there from what I have ever noticed. This is of course speculation from observation not reading the RFC and evalusting how the phone or Thunderbird implements it. It does seem to work pretty well though.

On the older phones with BIS, the BIS server would keep the same connection/session open for days at a time if not longer... so I don't think there is any real reason to disconnect and reconnect ever if the socket is kept open by even a single packet every half hour.

[dataiv]

IMAP IDLE RFC says the client just needs to reissue the IDLE command every half hour. So one packet every half hour to keep the socket open... well, in reality less than half an hour, 29 minutes as you stated.

But it doesn't need to log out, open a new connection, relogin, etc... just send IDLE again.

[Omnitech]

IMAP IDLE RFC says the client just needs to reissue the IDLE command every half hour. So one packet every half hour to keep the socket open... well, in reality less than half an hour, 29 minutes as you stated.

But it doesn't need to log out, open a new connection, relogin, etc... just send IDLE again.

Yes, which is why I often correct people who insist that IMAP IDLE still "polls". Not my definition of "poll".

But I don't know if the open socket requires the radio to remain on. That is the battery-life question. I would imagine that there would be some sort of mechanism to "spoof" that situation to allow the radio to remain off until actual packets are sent/received on the socket.

Also, new enhancements proposed to IMAP (in use various places but not technically part of the general IMAP standard yet) are designed to optimize performance/battery-life on mobile devices by, among other things, pipelining commands and allowing a single operation to perform what used to require multiple. (For example, I think that sending a message required a separate "send" and "resync" or something. Need to double-check.)

[dataiv]

But I don't know if the open socket requires the radio to remain on. That is the battery-life question. I would imagine that there would be some sort of mechanism to "spoof" that situation to allow the radio to remain off until actual packets are sent/received on the socket.

The radio goes to sleep. It's just like any other process, I think. Like in the past with BIS, when the network wants to send a message, it can wake the phone's radio up (somehow). I really don't know how this works but I suppose it must be similar to receiving phone calls as well. Radio is asleep and then it comes out of sleep mode with some command.

Anyway I have verified that sometimes 10s of minutes will go by before a packet is sent.. then the first packet sent to the phone over the network takes about 2-3 seconds to get a response (if it's a notification of a new message that is being sent through the idle socket). So I guess that is the radio waking up... first packet takes a few seconds to get handled and then the phone pulls the new message, and voila, new message in the inbox on the phone.

If you're using Gmail, I think one thing that could save some battery life is lengthening the time to sync for Contacts and Calendar, as these actually do sync every X seconds (whatever your sync setting for those accounts is), so I set mine to multiple hours as I really don't care that much on the timing of those syncs. Email is still using IMAP IDLE.

I have also confirmed that regardless of your sync setting for any IMAP accounts, if Push is enabled and the server supports IDLE, then the sync setting doesn't seem to have an effect. It doesn't do any data transfers based on that schedule, at least from what I can gather looking at tcpdump output on my IMAP server. It seems that what happens is that the phone gets notifications of changes, and unless it's a new message, it queues up the notifications and at some point in the future (I have been seeing 10-30 minutes, but it varies a lot) it processes them all at once (say you delete messages in your inbox from your computer). Whereas with a new message, it fetches it immediately. But it doesn't seem to be based on a "Sync Interval" as long as you are using IMAP IDLE. This seems reasonable... no need to immediately process and handle every IMAP notification that comes to the phone immediately as long as it does fully sync in a reasonable time frame.

[Omnitech]

I have also confirmed that regardless of your sync setting for any IMAP accounts, if Push is enabled and the server supports IDLE, then the sync setting doesn't seem to have an effect. It doesn't do any data transfers based on that schedule, at least from what I can gather looking at tcpdump output on my IMAP server. It seems that what happens is that the phone gets notifications of changes, and unless it's a new message, it queues up the notifications and at some point in the future (I have been seeing 10-30 minutes, but it varies a lot) it processes them all at once (say you delete messages in your inbox from your computer). Whereas with a new message, it fetches it immediately. But it doesn't seem to be based on a "Sync Interval" as long as you are using IMAP IDLE. This seems reasonable... no need to immediately process and handle every IMAP notification that comes to the phone immediately as long as it does fully sync in a reasonable time frame.

Well actually I think IMAP IDLE is not supposed to do anything but communicate state-changes in the monitored folders. To actually sync changes (moves, deletions, etc) you have to do a sync.

That's why people sometimes complain that they see notifications about new messages but they don't see status flags updated for a while. The notification can be almost instantaneous, but it will wait for the sync interval to synchronize folder/message state changes device <<----->> server.

[dataiv]

Yup. But the same open connection is used. So do your things, then enter IDLE, wait for a new message notification or other notifications. If new, then exit idle and fetch the new message then reenter idle. If other than new (delete, flag, etc) add it to the queue for future handling. That seems to be the way it works, anyway.

Works fine for me. The only thing I want to see immediately is new emails.

Posted via CB10

[Omnitech]

Yup. But the same open connection is used. So do your things, then enter IDLE, wait for a new message notification or other notifications. If new, then exit idle and fetch the new message then reenter idle. If other than new (delete, flag, etc) add it to the queue for future handling. That seems to be the way it works, anyway.

Works fine for me. The only thing I want to see immediately is new emails.

Well I'm not disagreeing it's a useful policy for some (and might save battery a little), just explaining why I think the things you are observing are happening that way. I think you probably have characterized that accurately.