Re: 2.0 and Radio Impacts/battery efficiency

Sorry, I may have misunderstood your previous statement. At my first read,
I thought it implied that the 30s idle time would mean connections with
hanging GETs that take longer than 30s would get closed while the GET is
hanging. Just wanted to clarify that that's not the case s'all.

On Sun, Apr 15, 2012 at 12:45 AM, Roberto Peon <grmocg@gmail.com> wrote:

> That is only true if the browser is reusing the same connection for the
> next request. If, as many do when doing AJAX, the app uses multiple
> overlapping GETs, it will use multiple connections and will be almost
> guaranteed to go idle at different times. This is made worse if the app
> makes other requests to the same domain (which must be done over separate
> connections...)
>
> Anyway, I think that there are so many things interplaying here that the
> only way to figure things out is to measure and study. It is certainly not
> something that has high determinism...
>
>
> -=R
> On Apr 14, 2012 4:58 PM, "William Chan (陈智昌)" <willchan@chromium.org>
> wrote:
>
>> 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
>>>>
>>>>
>>>
>>