Re: 2.0 and Radio Impacts/battery efficiency

[Salvatore Loreto <[e-mail]>]

On 4/13/12 12:45 PM, [e-mail] wrote:
>
> Hi,
>
> It’s not clear to me that using less _/TCP/_ connections automatically 
> reduces battery power on 3G. For instance, the use of battery is 
> roughly the same if a client opens a single TCP connection and 
> pipelines (or multiplexes in SPDY style) multiple GETs over it vs. 
> opens simultaneously a separate connection for each GET. The radio 
> wakes up on the first TCP SYN and stays up a few seconds after the 
> last byte in the last response has been obtained. A single connection 
> may or may not make this time shorter.
>
> How the connections are closed does potentially have an impact. If the 
> connections are closed immediately after the responses are done, there 
> isn’t any significant difference between 1 vs. many connections. The 
> radio is already up. However, if the connections are closed after some 
> idle period, for instance by a server timeout, that makes the radio 
> wake-up an additional time. If the separate connections are closed 
> after _/different/_ timeouts (more than a couple of seconds 
> difference), that can make the radio wake-up multiple times, which is 
> bad.
>
> If servers really do use random timeouts, I agree that fewer 
> connections are better. Is that the case?
>
yes, it is!
at least that is also my reading of the advices on the android developer 
website.

> If there are connections to multiple servers and servers send data in 
> an asynchronous and uncoordinated manner is a problem as the radio 
> wakes up quite often.  One solution is to use some kind of 
> gateway/proxy to buffer and bundle the data together and use just a 
> single connection to that gateway.
>

> Markus
>
> *From:*ext Salvatore Loreto [mailto:[e-mail]]
> *Sent:* 13 April, 2012 11:48
> *To:* Roberto Peon
> *Cc:* Zhong Yu; HTTP Working Group
> *Subject:* Re: 2.0 and Radio Impacts/battery efficiency
>
> Roberto is right!
>
> the problem with multiple TCP connections is that the server can send 
> packets on several connections.
>
> Low power to full power will always be the case no matter who send 
> data on (or closes) the connection, server or client.
> On top of this, when the server send data on (or closes) the 
> connection the system needs to page the device,
> send out a signal on the common control channel in order to make the 
> device re-establish its radio channel, these are in many systems quite 
> loaded.
> When the TCP close is initiated from the device the device does not 
> need to be paged.
>
> /Sal
>
> -- 
> Salvatore Loreto, PhD
> www.sloreto.com  <http://www.sloreto.com>
>
>
>
> On 4/13/12 9:27 AM, Roberto Peon wrote:
>
> The most obvious reason would be that the server sends a packet which 
> requires the radio to awaken (e.g. because the tcp stack emits a 
> packet back).
>
> -=R
>
> On Thu, Apr 12, 2012 at 8:23 AM, Zhong Yu <[e-mail] 
> <mailto:[e-mail]>> wrote:
>
> I don't get it. Cerntainly a new connection requires an extra round
> trip which drains extra power, but only for the duration of the round
> trip. Why is it "extremely expensive"?
>
> The article says
>
>    "Every time you create a new network connection, the radio
> transitions to the full power state."
>
> which I don't think implies that,
>
>    "If you reuse a network connection, the radio does NOT necessarily
> transition to the full power state."
>
> To compress all network activities(including FIN-FIN) into a shorter
> time span, the article event suggests that
>
>    "so it's also good practice to close your connections when they
> aren't in use"
>
>
>
> On Thu, Apr 12, 2012 at 3:52 AM, Salvatore Loreto
> <[e-mail] <mailto:[e-mail]>> 
> wrote:
> > Hi there,
> >
> > here a good read about "Optimizing Downloads for Efficient Network 
> Access"
> > 
> http://developer.android.com/training/efficient-downloads/efficient-network-access.html
> >
> > the major points are
> >
> > 1) reducing the number of connections is a MUST as each new network
> > connection is extremely expensive
> > from a Radio/Battery prospective
> >
> > It is also worth to add that the server-initiated closing of  idle
> > connection is also something to avoid.
> > So if the client keeps the connection open longer, then the 
> specification
> > has to mandate servers to keep
> > the connection open for very long.
> >
> >
> > 2) the ping frequency is also very important:
> > "An app that pings the server every 20 seconds, just to acknowledge 
> that the
> > app is running and visible to the user, will keep the radio powered on
> > indefinitely"
> >
> >
> > 3) also Prefetching data need some consideration from the radio 
> prospective
> > as Prefetching data (on a wireless connection)
> >  may cost money but for sure has a cost from a battery prospective
> >
> >
> > cheers
> > Sal
> >
> > --
> > Salvatore Loreto, PhD
> > www.sloreto.com <http://www.sloreto.com>
>