- From: Carsten Bormann <cabo@tzi.org>
- Date: Sat, 14 Apr 2012 22:07:29 +0200
- To: <Markus.Isomaki@nokia.com>
- Cc: <salvatore.loreto@ericsson.com>, <grmocg@gmail.com>, <zhong.j.yu@gmail.com>, <ietf-http-wg@w3.org>
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
Received on Saturday, 14 April 2012 20:08:07 UTC