Re: 2.0 and Radio Impacts/battery efficiency

On Sun, Apr 15, 2012 at 5:28 AM, William Chan (陈智昌)
<willchan@chromium.org>wrote:

> 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.


No, you were correct in your first interpretation: I certainly implied that
the hanging get for 30s may be interpreted as idle.
I'm just pointing out here that the fact that apache is smart enough to
know that a non-responded to request isn't idle just doesn't mean it won't
still happen.
-=R


>
>
> 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
>>>>>
>>>>>
>>>>
>>>
>