W3C home > Mailing lists > Public > ietf-http-wg@w3.org > April to June 2014

Re: Will HTTP/2.0 be green ?

From: Roberto Peon <grmocg@gmail.com>
Date: Sun, 1 Jun 2014 13:13:06 -0700
Message-ID: <CAP+FsNehJkfSsnJ9=1d6joCgsskuyfiiUGb5fGp4L0QYgVO7SQ@mail.gmail.com>
To: Poul-Henning Kamp <phk@phk.freebsd.dk>
Cc: HTTP Working Group <ietf-http-wg@w3.org>
You're missing out on all of the other second order effects.

As examples, things that increase latency, increase the time
spectrum/channels are in use, requiring the radio to be on for longer,
requiring the CPU to be active for longer, requiring the display to be
active for longer, etc.
CPU is often far less costly than keeping the radio or screen on. Powering
a radio or screen is often accomplished via a battery, which has a less
than 100% energy efficiency, etc. etc.


On Sun, Jun 1, 2014 at 1:00 PM, Poul-Henning Kamp <phk@phk.freebsd.dk>

> In the discussion about compression, and for that matter
> encryption, we need to talk a bit about greenhouse gasses.
> Any one microsecond, any one kilobyte of extra per-hop cost per
> HTTP request, is going to scale into remarkable amounts of greenhouse
> gasses by the time it is scaled up across the WWW.
> Ideally, we should be able to show that processing the same
> workload with HTTP/2.0 takes no more energy than with HTTP/1.1,
> and preferably less.
> A small power increment for significant performance gains can
> probably be "sold" with some hand-waving.
> Having HTTP/2.0 use significantly more energy than HTTP/1.1
> would make the protocol a non-starter.  Just imagine the
> gleeful CS/EE student papers and resulting headlines.
> Poul-Henning
> PS:  Speaking from a lot of experience, the most manageable way to
> measure power consumption realtive to workload is to use really
> small computers, RasberryPI, BeagleBone, Soekris etc. where the
> measurements can be done on the low voltage DC supply.
> If anybody wants to persue this, I'll be happy to help out.
> Drop me email.
> --
> Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
> phk@FreeBSD.ORG         | TCP/IP since RFC 956
> FreeBSD committer       | BSD since 4.3-tahoe
> Never attribute to malice what can adequately be explained by incompetence.
Received on Sunday, 1 June 2014 20:13:33 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:31 UTC