Re: 2.0 and Radio Impacts/battery efficiency
Roberto Peon <grmocg@gmail.com> Sun, 15 April 2012 18:43 UTC
Return-Path: <ietf-http-wg-request@listhub.w3.org>
X-Original-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Delivered-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7385321F8805 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Sun, 15 Apr 2012 11:43:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.286
X-Spam-Level:
X-Spam-Status: No, score=-10.286 tagged_above=-999 required=5 tests=[AWL=0.012, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xzrny16UI9Tz for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Sun, 15 Apr 2012 11:43:36 -0700 (PDT)
Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by ietfa.amsl.com (Postfix) with ESMTP id F0AFF21F8806 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Sun, 15 Apr 2012 11:43:35 -0700 (PDT)
Received: from lists by frink.w3.org with local (Exim 4.69) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1SJUOn-0007G3-Bu for ietf-http-wg-dist@listhub.w3.org; Sun, 15 Apr 2012 18:42:09 +0000
Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.69) (envelope-from <grmocg@gmail.com>) id 1SJUOa-0007Ad-KJ for ietf-http-wg@listhub.w3.org; Sun, 15 Apr 2012 18:41:56 +0000
Received: from mail-ob0-f171.google.com ([209.85.214.171]) by lisa.w3.org with esmtp (Exim 4.72) (envelope-from <grmocg@gmail.com>) id 1SJUOW-0002uR-Vw for ietf-http-wg@w3.org; Sun, 15 Apr 2012 18:41:54 +0000
Received: by obbtb18 with SMTP id tb18so1259170obb.2 for <ietf-http-wg@w3.org>; Sun, 15 Apr 2012 11:41:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Br+S5ChUxO2RC/rH7gNRRRB6K8Y3WWAy6kiPOH8pzek=; b=gNG2jmNAPVwyZJ/pr4uA88LieccUglSCMT5NhNZ/DP+jAC/7F0LRjrXbZ451t1tcMA vOj5SsHyMrQoiQ3a6zCUP+rIWcuZdV4h4wp0Faav8bRxhNrjO83ncbF9visfmzFGz3uU k8jeTR4SKkSwgH2susN+FV7ysEUm4/HpmDMnVx/Wk9gXQ8rKinnoD2aeXGpVusE8XJnP oWNAkzE73q/2cVh+v+ai859zvPDB+E4UlKED9G1eedhUz3ihAHLIVNXp1f7yF32t3Bho 6QRDxTcjK5PWr3gKktHA3ka+S97QSdQs1nXPekK/Z+5cD0o8Gqd9aDmzpIp1K4KNvj0D GTlw==
MIME-Version: 1.0
Received: by 10.182.112.41 with SMTP id in9mr12352890obb.40.1334515287605; Sun, 15 Apr 2012 11:41:27 -0700 (PDT)
Received: by 10.182.109.102 with HTTP; Sun, 15 Apr 2012 11:41:27 -0700 (PDT)
In-Reply-To: <CAA4WUYhzwAvneM1kPP=uW-yDrFgEe+ccH-CUB5ARBN-Ou3oP3A@mail.gmail.com>
References: <4F8697C2.5000702@ericsson.com> <CACuKZqGA9Tyv_zhO2HhyLNvqvzNCrTyZYy+b_Tt616F7eLbT1w@mail.gmail.com> <CAP+FsNcGfj_G1U9nWA5qj+tW8rWwMn0+HVhYA40XXQg_hWfTuA@mail.gmail.com> <4F87E856.1000604@ericsson.com> <E44893DD4E290745BB608EB23FDDB7621CEF37@008-AM1MPN1-041.mgdnok.nokia.com> <7180B750-BD93-4E2D-9506-E186A5CA87F6@tzi.org> <CAP+FsNcL=GmbMB5F9ByAF3EOP2iiKKCYk=O0vkduSArci6B4qw@mail.gmail.com> <CAA4WUYgPCAdgVEZ3ky4wH+UYKnO7FQofXbmsEPbXGWZA9j5-Dw@mail.gmail.com> <CAP+FsNeHpwmw8MAYKY5zYqG+M3eTe-PH7pkT076u8WWB6v1maw@mail.gmail.com> <CAA4WUYhzwAvneM1kPP=uW-yDrFgEe+ccH-CUB5ARBN-Ou3oP3A@mail.gmail.com>
Date: Sun, 15 Apr 2012 11:41:27 -0700
Message-ID: <CAP+FsNf8YO0VNkw39LNrvuHamvrdw-TqYLQAjr+jLEoc1RZrag@mail.gmail.com>
From: Roberto Peon <grmocg@gmail.com>
To: "William Chan (陈智昌)" <willchan@chromium.org>
Cc: Carsten Bormann <cabo@tzi.org>, Markus.Isomaki@nokia.com, salvatore.loreto@ericsson.com, zhong.j.yu@gmail.com, ietf-http-wg@w3.org
Content-Type: multipart/alternative; boundary="f46d04479451aa411f04bdbc0d52"
Received-SPF: pass client-ip=209.85.214.171; envelope-from=grmocg@gmail.com; helo=mail-ob0-f171.google.com
X-W3C-Hub-Spam-Status: No, score=-2.7
X-W3C-Hub-Spam-Report: BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001
X-W3C-Scan-Sig: lisa.w3.org 1SJUOW-0002uR-Vw efa085f463f0d2c6eea00dd7df1626df
X-Original-To: ietf-http-wg@w3.org
Subject: Re: 2.0 and Radio Impacts/battery efficiency
Archived-At: <http://www.w3.org/mid/CAP+FsNf8YO0VNkw39LNrvuHamvrdw-TqYLQAjr+jLEoc1RZrag@mail.gmail.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/13450
X-Loop: ietf-http-wg@w3.org
Resent-Sender: ietf-http-wg-request@w3.org
Precedence: list
List-Id: <ietf-http-wg.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Post: <mailto:ietf-http-wg@w3.org>
List-Unsubscribe: <mailto:ietf-http-wg-request@w3.org?subject=unsubscribe>
Resent-Message-Id: <E1SJUOn-0007G3-Bu@frink.w3.org>
Resent-Date: Sun, 15 Apr 2012 18:42:09 +0000
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 >>>>> >>>>> >>>> >>> >
- 2.0 and Radio Impacts/battery efficiency Salvatore Loreto
- Re: 2.0 and Radio Impacts/battery efficiency Zhong Yu
- Re: 2.0 and Radio Impacts/battery efficiency William Chan (陈智昌)
- Re: 2.0 and Radio Impacts/battery efficiency Roberto Peon
- Re: 2.0 and Radio Impacts/battery efficiency Salvatore Loreto
- RE: 2.0 and Radio Impacts/battery efficiency Markus.Isomaki
- Re: 2.0 and Radio Impacts/battery efficiency Salvatore Loreto
- RE: 2.0 and Radio Impacts/battery efficiency Roberto Peon
- RE: 2.0 and Radio Impacts/battery efficiency Roberto Peon
- Re: 2.0 and Radio Impacts/battery efficiency Willy Tarreau
- Re: 2.0 and Radio Impacts/battery efficiency Carsten Bormann
- Re: 2.0 and Radio Impacts/battery efficiency Roberto Peon
- Re: 2.0 and Radio Impacts/battery efficiency William Chan (陈智昌)
- Re: 2.0 and Radio Impacts/battery efficiency Roberto Peon
- Re: 2.0 and Radio Impacts/battery efficiency William Chan (陈智昌)
- Re: 2.0 and Radio Impacts/battery efficiency Roberto Peon