Yes, but even if polling were to reset the arp cache timer at the router, by definition, the arp timer would have to be shorter than 15 minutes in order for the GMail push feature problem to be present.
Even if you have set your device to "push" setting instead of regular polling, the device restores the port 5228 connection every 15 minutes in order to retrieve mail.
So, I don't see how polling would be any better than just letting your device retrieve its mails every 15 minutes.
I'm not familiar with how Google push mail is actually implemented... but if it is simply a case of having an open TCP session with Google servers, then that won't necessarily refresh arp caches. Perhaps my memory is failing me but TCP connections can remain open indefinitely (if desired) without having any traffic for a long time (certainly longer than 2 minutes). (Otherwise, there'd be no need for explicit TCP keep-alives.)
Sorry, perhaps I missed your point...but that was the original reason for the bcast mod or static arp, Without these workarounds, the N4 doesn't send anything to Google servers and unsolicited data from the servers can't reach the N4.
I only used polled email as an example of a potential workaround but I really wouldn't want to poll mail (or weather) that frequently. (It actually requires quite a bit of processing for session creation/tear-down ... especially if retries are required.) I suspect that a compromise solution would be to have the N4 issue gratuitous arps every minute or two. (No connection establishment. No waiting for ack's. So the device can resume deep-sleep quicker.)
Even still, on the third line of your table you show over 7 hours of standby with no battery loss, despite 2-3 minutes of awake time? Surely your wifi radio had been turned on which would have consumed more power than that?
But, even in the absence of broadcast replies (no static arp entries or no wifi "fixes"), the device seems to wake itself and reconnect over port 5228, and once established, one receives email ... Perhaps it can be considered "polling" after all if the net result is the same.
Purely speculation... but I suspect that the broadcast filter issue was known to Android devs as a conscious choice to conserve battery. When they included options like "WiFi optimization" and "leave WiFi on during sleep", someone would have surely tested by pushing data to the N4. But while ignoring broadcasts, perhaps they forgot to switch from push mail to polling (before going to deep sleep). (Polling would have at least reset the arp cache timer. Perhaps their testers had polled exchange mail, etc running which hid the problem.)
I have noticed with my nexus 4 that even though the wifi connection setting states 'always on', when I have my phone connected to the outlet and idle, that I have no connection issues connecting to ssh on my nx4. However, on the battery and idle, connection issues persist.
Broadcast On Battery Awake Battery% (Total Drop) Disallowed 7h50 3 mins ( 0.6%) ~0 3G 7h56 7 mins ( 1.5%) ~1% --- previously (with the prev version of kernel) Allowed 5h59 32 mins ( 8.9%) -4% Allowed 5h50 36 mins (10.3%) -5%
|Thread Tools||Search this Thread|