RE: 2.0 and Radio Impacts/battery efficiency

[Roberto Peon <[e-mail]>]

Any timeout, if not explicitly synchronized across connections (dang
difficult) will , since the connection becomes idle/empty at different
times, will result in some random distribution of fins/backs/whathaveyou.
On Apr 13, 2012 3:45 AM, <[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?****
>
> ** **
>
> 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****
>
>
>
> 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]> 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]> 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****
>
> ** **
>
> ** **
>