- From: Mike Belshe <mike@belshe.com>
- Date: Sun, 1 Jun 2014 14:32:48 -0700
- To: Poul-Henning Kamp <phk@phk.freebsd.dk>
- Cc: HTTP Working Group <ietf-http-wg@w3.org>
- Message-ID: <CABaLYCvTVJ+6nvFEnhKFyn-dYvSGNhJBsmpfhAAGtVdhj_gs0w@mail.gmail.com>
I would be interested in seeing a useful study here. However, the best study would be one done in production environments rather than on simulated devices with simulated models. It would just be really hard to get a realistic model. Regardless, however, using less power wasn't an of objective in building HTTP. To revisit the requirements at this late stage is not a good idea. We should stick to the plan. Mike On Sun, Jun 1, 2014 at 1:00 PM, Poul-Henning Kamp <phk@phk.freebsd.dk> wrote: > > 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 21:33:16 UTC