IETF Logo Mail Archive

Re: [recipe] FYI: [admin-discuss] REMINDER: IETF carbon emission measurement workshops on 20 and 21 September

Michael Welzl <michawe@ifi.uio.no> Mon, 26 September 2022 06:31 UTC

Return-Path: <michawe@ifi.uio.no>
X-Original-To: recipe@ietfa.amsl.com
Delivered-To: recipe@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34278C1524B9 for <recipe@ietfa.amsl.com>; Sun, 25 Sep 2022 23:31:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.909
X-Spam-Level:
X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VRDyAp6lrBhd for <recipe@ietfa.amsl.com>; Sun, 25 Sep 2022 23:31:27 -0700 (PDT)
Received: from mail-out04.uio.no (mail-out04.uio.no [IPv6:2001:700:100:8210::76]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ABE5FC1524B5 for <recipe@ietf.org>; Sun, 25 Sep 2022 23:31:26 -0700 (PDT)
Received: from mail-mx04.uio.no ([129.240.10.25]) by mail-out04.uio.no with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.95) (envelope-from <michawe@ifi.uio.no>) id 1ocheA-00BsQc-Ai; Mon, 26 Sep 2022 08:31:18 +0200
Received: from [185.176.244.72] (helo=smtpclient.apple) by mail-mx04.uio.no with esmtpsa (TLS1.2:ECDHE-RSA-AES256-GCM-SHA384:256) user michawe (Exim 4.95) (envelope-from <michawe@ifi.uio.no>) id 1oche9-00009m-P9; Mon, 26 Sep 2022 08:31:18 +0200
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.120.41.1.1\))
From: Michael Welzl <michawe@ifi.uio.no>
In-Reply-To: <YzDNTByMvA9tsE5c@faui48e.informatik.uni-erlangen.de>
Date: Mon, 26 Sep 2022 08:31:08 +0200
Cc: Cedric Westphal <cedric.westphal@futurewei.com>, recipe@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <2AD22503-6EA8-4055-839D-04F569C29B7E@ifi.uio.no>
References: <Yy87opj7tkqfd85I@faui48e.informatik.uni-erlangen.de> <D3A1335A-022C-4F1F-BCCC-3160B1D3BB7C@ifi.uio.no> <YzDNTByMvA9tsE5c@faui48e.informatik.uni-erlangen.de>
To: Toerless Eckert <tte@cs.fau.de>
X-Mailer: Apple Mail (2.3696.120.41.1.1)
X-UiO-SPF-Received: Received-SPF: neutral (mail-mx04.uio.no: 185.176.244.72 is neither permitted nor denied by domain of ifi.uio.no) client-ip=185.176.244.72; envelope-from=michawe@ifi.uio.no; helo=smtpclient.apple;
X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, AWL=0.013, UIO_MAIL_IS_INTERNAL=-5)
X-UiO-Scanned: 43F2CF0AF092F707A208854A19E4C9A945ADD8FA
X-UiOonly: C68F8E3366ACF7DEE67F022AC9F928AA734906CD
Archived-At: <https://mailarchive.ietf.org/arch/msg/recipe/U68_on_to-e4Jniox8eRQGHVk1E>
Subject: Re: [recipe] FYI: [admin-discuss] REMINDER: IETF carbon emission measurement workshops on 20 and 21 September
X-BeenThere: recipe@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: "RECIPE \(Reducing Energy Consumption with Internet Protocols Exploration\)" <recipe.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/recipe>, <mailto:recipe-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/recipe/>
List-Post: <mailto:recipe@ietf.org>
List-Help: <mailto:recipe-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/recipe>, <mailto:recipe-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 26 Sep 2022 06:31:29 -0000


> On Sep 25, 2022, at 11:51 PM, Toerless Eckert <tte@cs.fau.de> wrote:
> 
> On Sun, Sep 25, 2022 at 11:57:44AM +0200, Michael Welzl wrote:
>>> So my
>>> primary question is: are there any "natural" limits in linearizing this curve ? Then as a pessimist,
>>> i would love to design / evaluate against those limits instead of against the inferior hardware we have
>>> today. Especially because i only need to look at mobile device HW/CPU to see that there is a
>>> lot of room for improvement (AFAIK).
>> 
>> I guess this is about evaluating the cost of sleep/awake transitioning over the years…  how has this evolved, will it become miniscule?
> 
> Indeed. I am just worried that it do not know that it will not become miniscule, which
> makes me somewhat worried into promoting investing into solutions that depend on it
> not being miniscule. After all, we have past experiences with betting investments into
> assumptions that turned out to be changed inparallel, rendering the investments mostly void.
> 
> Aka: Would love to see, if research can also come up with predictions about this factor
> (non minisculity of transitioning, if that's even a word ;-)

:-)    +1 though… btw this is about being miniscule both in terms of energy cost and time.

Cheers,
Michael

v2.23.0 | Report a Bug | By Email