Re: 2.0 and Radio Impacts/battery efficiency

Roberto Peon <grmocg@gmail.com> Fri, 13 April 2012 07:29 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 986B621F86A2 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Fri, 13 Apr 2012 00:29:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.401
X-Spam-Level:
X-Spam-Status: No, score=-10.401 tagged_above=-999 required=5 tests=[AWL=0.197, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 MWIMcgdNqUHH for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Fri, 13 Apr 2012 00:29:02 -0700 (PDT)
Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by ietfa.amsl.com (Postfix) with ESMTP id 71AE221F8608 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Fri, 13 Apr 2012 00:28:58 -0700 (PDT)
Received: from lists by frink.w3.org with local (Exim 4.69) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1SIavN-00080j-5q for ietf-http-wg-dist@listhub.w3.org; Fri, 13 Apr 2012 07:28:05 +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 1SIav7-0007yW-Vh for ietf-http-wg@listhub.w3.org; Fri, 13 Apr 2012 07:27:50 +0000
Received: from mail-vb0-f43.google.com ([209.85.212.43]) by lisa.w3.org with esmtp (Exim 4.72) (envelope-from <grmocg@gmail.com>) id 1SIav4-0005sI-W6 for ietf-http-wg@w3.org; Fri, 13 Apr 2012 07:27:48 +0000
Received: by vbbfq11 with SMTP id fq11so2607906vbb.2 for <ietf-http-wg@w3.org>; Fri, 13 Apr 2012 00:27:21 -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=lC9EEcqTIJw1YSJo81pRUYc4iEnVw7D/htglVBkGWKY=; b=XbJAsDHhiCZdv7GP44GpGnpb4Iv00oOHYljpGS+i72HTQ3VgArlu/3F6IvMUHTHRaP VaB1XwNFIeh4+RoLsVOgdAOOdKjw4IGicNq+WOXO1bEgMuvbDuHHbGqKidkjBeMchgrB e5VmKmUUGDALY6H0pR9pYkpCuVHMtj7DZ3aleoA4QRwNxiVUM230JgEVshMap+dWp1HU 9Y8yIaRfVUEyEbW/TnYjqQGtdqelt9OdcHEkNWbbYYe21BZ/lKsIhxHqYXB8xNGWSxVd 3kDvAFxnYarXFEn/FDifltviVSOO7IJyHMPGmm34bOgj9SvNAzmWm1XPp0ZHkgJu+zdr PMrQ==
MIME-Version: 1.0
Received: by 10.52.72.130 with SMTP id d2mr240359vdv.80.1334302041321; Fri, 13 Apr 2012 00:27:21 -0700 (PDT)
Received: by 10.52.34.103 with HTTP; Fri, 13 Apr 2012 00:27:21 -0700 (PDT)
In-Reply-To: <CACuKZqGA9Tyv_zhO2HhyLNvqvzNCrTyZYy+b_Tt616F7eLbT1w@mail.gmail.com>
References: <4F8697C2.5000702@ericsson.com> <CACuKZqGA9Tyv_zhO2HhyLNvqvzNCrTyZYy+b_Tt616F7eLbT1w@mail.gmail.com>
Date: Fri, 13 Apr 2012 00:27:21 -0700
Message-ID: <CAP+FsNcGfj_G1U9nWA5qj+tW8rWwMn0+HVhYA40XXQg_hWfTuA@mail.gmail.com>
From: Roberto Peon <grmocg@gmail.com>
To: Zhong Yu <zhong.j.yu@gmail.com>
Cc: Salvatore Loreto <salvatore.loreto@ericsson.com>, HTTP Working Group <ietf-http-wg@w3.org>
Content-Type: multipart/alternative; boundary="bcaec501654932311d04bd8a678d"
Received-SPF: pass client-ip=209.85.212.43; envelope-from=grmocg@gmail.com; helo=mail-vb0-f43.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 1SIav4-0005sI-W6 a2f28a1f56e7f69716590df5f3e639ff
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+FsNcGfj_G1U9nWA5qj+tW8rWwMn0+HVhYA40XXQg_hWfTuA@mail.gmail.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/13435
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: <E1SIavN-00080j-5q@frink.w3.org>
Resent-Date: Fri, 13 Apr 2012 07:28:05 +0000

The most obvious reason would be that the server sends a packet which
requires the radio to awaken (e.g. because the tcp stack emits a packet
back).
-=R

On Thu, Apr 12, 2012 at 8:23 AM, Zhong Yu <zhong.j.yu@gmail.com> wrote:

> I don't get it. Cerntainly a new connection requires an extra round
> trip which drains extra power, but only for the duration of the round
> trip. Why is it "extremely expensive"?
>
> The article says
>
>    "Every time you create a new network connection, the radio
> transitions to the full power state."
>
> which I don't think implies that,
>
>    "If you reuse a network connection, the radio does NOT necessarily
> transition to the full power state."
>
> To compress all network activities(including FIN-FIN) into a shorter
> time span, the article event suggests that
>
>    "so it's also good practice to close your connections when they
> aren't in use"
>
>
> On Thu, Apr 12, 2012 at 3:52 AM, Salvatore Loreto
> <salvatore.loreto@ericsson.com> wrote:
> > Hi there,
> >
> > here a good read about "Optimizing Downloads for Efficient Network
> Access"
> >
> http://developer.android.com/training/efficient-downloads/efficient-network-access.html
> >
> > the major points are
> >
> > 1) reducing the number of connections is a MUST as each new network
> > connection is extremely expensive
> > from a Radio/Battery prospective
> >
> > It is also worth to add that the server-initiated closing of  idle
> > connection is also something to avoid.
> > So if the client keeps the connection open longer, then the specification
> > has to mandate servers to keep
> > the connection open for very long.
> >
> >
> > 2) the ping frequency is also very important:
> > "An app that pings the server every 20 seconds, just to acknowledge that
> the
> > app is running and visible to the user, will keep the radio powered on
> > indefinitely"
> >
> >
> > 3) also Prefetching data need some consideration from the radio
> prospective
> > as Prefetching data (on a wireless connection)
> >  may cost money but for sure has a cost from a battery prospective
> >
> >
> > cheers
> > Sal
> >
> > --
> > Salvatore Loreto, PhD
> > www.sloreto.com
>
>