Re: 2.0 and Radio Impacts/battery efficiency

On Sat, Apr 14, 2012 at 2:11 PM, Roberto Peon <grmocg@gmail.com> wrote:

> First: There needs to be better integration between the transport, app,
> and hardware/radio on this in order to vastly improve the situation.
>
> Second: Setting keep-alive to such low values can also adversely impact
> battery, depending on the pattern of connection use, as it will increase
> (significantly) latency for getting the user what they want. Additionally
> many chat clients and/or ajax sites will use "hanging" gets, which return
> perhaps every 30s. Even using a bidirectional stream (e.g. WebSockets),
> this problem persists.


Just to be clear, I believe Apache's KeepAliveTimeout refers to the idle
time at the server after a HTTP transaction completes before Apache closes
the socket. So hanging GETs should be fine since those HTTP transactions
are active.


>
> Until there is a study looking at what many websites do on devices from
> various carriers, any supposition about reducing or increasing timeouts and
> the impact on battery is just hypothetical supposition.
>
> One thing is clear, however: Regardless of the usage pattern, use of a
> proxy will reduce the number of extraneous radio wake-ups.
> -=R
>
>
> On Sat, Apr 14, 2012 at 1:07 PM, Carsten Bormann <cabo@tzi.org> wrote:
>
>> On Apr 13, 2012, at 12:45, <Markus.Isomaki@nokia.com> wrote:
>>
>> > 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.
>>
>> I haven't measured this, but looking at the docs leads to the following
>> conjectures:
>> The Apache 2.0 KeepAliveTimeout default was 15 seconds.  With the 17
>> seconds the AT&T parameters take to power down the radio and the 2 s to
>> power up again, this would lead to a total of 15+2+17 = 34 seconds to power
>> down.
>> The Apache 2.2 KeepAliveTimeout default is 5 seconds.  With any latency,
>> this appears to make sure the radio has just been put to low power only to
>> go through a 1.5 s transition to full power again (unless the FIN can be
>> handled on the FACH -- I don't know).
>>
>> Summary: With the AT&T numbers cited here, you could do your mobile users
>> a favor by setting KeepAliveTimeout to 4 or less seconds.
>>
>> (Find more about the 3G states and their timing in
>> http://www.pasieronen.com/publications/haverinen_siren_eronen_vtc2007.pdf-- this has a much smaller T2 than the 15 seconds the Android docs cite.
>> One interesting number in
>> http://research.nokia.com/files/tr/NRC-TR-2008-002.pdf was that a single
>> keep-alive exchange on their 3G network costs 9200 mJ (as opposed to 280 mJ
>> on WiFi), about 0.7 mAh on a 3.7 V battery.  You might have some 2000 of
>> those keep-alives in your cellphone battery before it is gone.  Ouch.)
>>
>> Grüße, Carsten
>>
>>
>