From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wr1-x434.google.com (mail-wr1-x434.google.com [IPv6:2a00:1450:4864:20::434]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 5E0313CB47 for ; Sat, 24 Nov 2018 06:49:52 -0500 (EST) Received: by mail-wr1-x434.google.com with SMTP id 96so14509576wrb.2 for ; Sat, 24 Nov 2018 03:49:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=heistp.net; s=google; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=D0yaQP9yshGih6SLKVi/XVw8AC9KXOdKHDTik833kgo=; b=h136dFFjW/Mp1UivQljByMTZKh/uZPxtPmbl89ymbQS/5YeUr/3Mf7tpvAyQFTeQ+8 dt0S4NYrTdhI+aFMUpLCmQQtikRBuF2lvaWNJ/698sFaExUM74o7Xx5GeE+p7faHMPF5 YAFWfa6RK8mBtj3+l2Hdin2jmmEDiBUed6jc5pPrQoJhf5O5O1xy6uOWnlVAt5LSlecj 5TMvuhVN1j2hGGBag+d9qIKTHX9ca95Qc1JeqVDfqRjtwB0GD/ZIyJGiAXgjddURg4fb DCGs/+ePjeSc4iyffk+dCdtIGfCJTca+QqAnXDBItFaRKMmksPtXiqCdYYTLtutY1v8M HMhQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=D0yaQP9yshGih6SLKVi/XVw8AC9KXOdKHDTik833kgo=; b=JAvJkv8psJC/XuDvoE7wucnc+xQUOwB+VLRzh7fAvZD2KBHGgyMO1eowZEJBWS40yC V40se21dbggTV5odfMnpwdxj5iKv96iFzI9OFcpMjjLVvAg2ZjKFZ0Q0/XjFJcu+8mRX hqYjkvUOhdgVOWKYtS7JxKSrg2o/0hVcQFrwlOzvQFVI7EP6xEtKlPxnayuHPXRe+oGj INq/fjy45zbN0bNtKUjiKUZZQ22+IxiAL011cpFAQ13TcphOM1N+76eTt9n01zDT0/dA 0y1cDEn9tB7Cge5DhTrQ+KVNJ1Le3UqilLHT8aUMe0chHx/Ul8J7GEffsQ/qcMDVw+xX LC7A== X-Gm-Message-State: AA+aEWY3b4Qtq1zgd7Nnb0hw2EMdrh/k1vya+UAtODaCJW3gl5FQ3Oom ZCWRSsr1NpILqkSlnZXgoLx9s3OCN/s= X-Google-Smtp-Source: AFSGD/WSN9yZxOtWWI6jg2IOCvey51iVONxsUcm2DM3CAJvia6uIe7EvVj8Ce+S7jbfYRI45hYThOw== X-Received: by 2002:adf:b592:: with SMTP id c18mr11085054wre.89.1543060191325; Sat, 24 Nov 2018 03:49:51 -0800 (PST) Received: from tron.luk.heistp.net (h-1169.lbcfree.net. [185.193.85.130]) by smtp.gmail.com with ESMTPSA id y145sm2786621wmd.30.2018.11.24.03.49.50 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 24 Nov 2018 03:49:50 -0800 (PST) From: Pete Heist Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_4C2CAC6D-2824-4C46-BF47-EE9F78BEB33C" Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Date: Sat, 24 Nov 2018 12:49:49 +0100 In-Reply-To: <87r2fbzrng.fsf@taht.net> Cc: bloat To: Dave Taht References: <6C1479A8-43E8-4F89-BCEA-1D28CA3E8589@heistp.net> <87r2fbzrng.fsf@taht.net> X-Mailer: Apple Mail (2.3445.9.1) Subject: Re: [Bloat] one benefit of turning off shaping + fq_codel X-BeenThere: bloat@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: General list for discussing Bufferbloat List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Nov 2018 11:49:52 -0000 --Apple-Mail=_4C2CAC6D-2824-4C46-BF47-EE9F78BEB33C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Nov 23, 2018, at 5:26 PM, Dave Taht wrote: >=20 > Pete Heist writes: >=20 >> Would it be right to say that the biggest opportunity for reducing >> consumption is to avoid shaping, i.e. by adding BQL-like = functionality >> to all classes of device drivers >=20 > Shaping outbound with BQL's support for a dynamic interrupt would be > *free*. A few ethernet chips already have that. Basically you set a > register saying "you are really a 200Mbit interface, return a = completion > interrupt after the equivalent of that amount of time has passed=E2=80=9D= . Ok, for Intel I see something called =E2=80=9CInterrupt Rate Limiting=E2=80= =9D on the XL710 which sets the number of microseconds between = interrupts (section 4.2 in = https://www.intel.com/content/dam/www/public/us/en/documents/reference-gui= des/xl710-x710-performance-tuning-linux-guide.pdf = ). I don=E2=80=99t = think that=E2=80=99s exactly it though. I also wanted to suggest that something =E2=80=9CBQL-like=E2=80=9D be = added to WiFi (I already saw discussion of that in make-wifi-fast), ADSL = (I guess that=E2=80=99s mostly proprietary stuff though?) or other techs = where it=E2=80=99s needed, so that we stop shaping whenever possible, = which as Toke mentioned in his defense is really a workaround anyway. I = feel guilty now shaping. > I can neither remember what chips can do this already, or the name of > the bql feature that does it, this morning. >=20 > But it's a register you twiddle and a simple divider circuit. It sounds like there won=E2=80=99t always be fine-grained control over = the rate. > But outbound is not the problem for us from a heat generation = standpoint=E2=80=A6 Actually, why is inbound shaping that much harder on the CPU than = outbound? >> and/or by deploying congestion control globally that avoids the need = for it? >=20 > I think it would be interesting to compare energy per byte = successfully > delivered across various technologies. Driving fiber lines is pretty > high energy, though, and I think (without a back of envelope handy), > that that would be far more expensive than shaping currently is. >=20 > still, adding 6 C to everybody's home router to shape inbound under > heavy load is pretty costly both in energy and reduced service life. I=E2=80=99m intrigued, and care about this topic. A few watts on = millions of devices might at least make some difference. Analyzing where = we stand in terms of energy per byte for different techs, and also what = shaping does to this, might be a place to start. >> Other ideas: move queue management into hardware >=20 > I have increasingly high hopes for P4 and other forms of hardware to > finally do shaping and queue management right. >=20 > https://github.com/ralfkundel/p4-codel/issues/2 >=20 > Back in the day, I was a huge fan of async logic, which I first > encountered via caltech's cpu and later the amulet. >=20 > https://en.wikipedia.org/wiki/Asynchronous_circuit#Asynchronous_CPU >=20 > This reduces power consumption enormously. There are things that make so much sense as to seem that they must = eventually happen, and this is one of those things. >> power network >> equipment with renewables, or just use the Internet less. :) >=20 > I am glad to see more of the former happening. A recent data center > design in singapore basically needed it's own nuclear power plant. At least it doesn=E2=80=99t emit CO2. :) I=E2=80=99m in the process of = trying to make a low-cost solar/battery setup for my home equipment. It = seems that a system that works ~100% of the time can be much more = expensive than one that works ~95% of the time, especially in central = Europe=E2=80=99s winters where cloudy streaks can last weeks, so I=E2=80=99= m probably accepting grid as a backup. > In my case I've always wanted the computing to take place under the > users fingers, I do not like the centralization trend we are in today = at > all. I like that apple seems to be leading the way to be putting all > these cool new AI tools in your own hands. >=20 > As for the latter... I'm using browsers less now (emacs rocks), and > seem to be getting more done. I=E2=80=99m with you, only =E2=80=98:s/emacs/vim/g=E2=80=99, but we = won=E2=80=99t start that. :) --Apple-Mail=_4C2CAC6D-2824-4C46-BF47-EE9F78BEB33C Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On = Nov 23, 2018, at 5:26 PM, Dave Taht <dave@taht.net> wrote:

Pete = Heist <pete@heistp.net> writes:

Would it be right to say = that the biggest opportunity for reducing
consumption is = to avoid shaping, i.e. by adding BQL-like functionality
to = all classes of device drivers

Shaping outbound with BQL's support for a dynamic interrupt = would be
*free*. A few ethernet chips already have that. = Basically you set a
register saying "you are really a = 200Mbit interface, return a completion
interrupt after the = equivalent of that amount of time has passed=E2=80=9D.

Ok, = for Intel I see something called =E2=80=9CInterrupt Rate Limiting=E2=80=9D= on the XL710 which sets the number of microseconds between interrupts = (section 4.2 in https://www.intel.com/content/dam/www/public/us/en/documents/re= ference-guides/xl710-x710-performance-tuning-linux-guide.pdf). I = don=E2=80=99t think that=E2=80=99s exactly it though.

I also wanted to suggest that something = =E2=80=9CBQL-like=E2=80=9D be added to WiFi (I already saw discussion of = that in make-wifi-fast), ADSL (I guess that=E2=80=99s mostly proprietary = stuff though?) or other techs where it=E2=80=99s needed, so that we stop = shaping whenever possible, which as Toke mentioned in his defense is = really a workaround anyway. I feel guilty now shaping.

I can neither remember what chips can do this already, or the = name of
the bql feature that does it, this morning.

But it's a register you twiddle and a simple = divider circuit.

It sounds like there won=E2=80=99t always be = fine-grained control over the rate.

But outbound is = not the problem for us from a heat generation = standpoint=E2=80=A6

Actually, why is inbound shaping that much harder = on the CPU than outbound?

and/or by deploying congestion control globally that avoids = the need for it?

I think it = would be  interesting to compare energy per byte successfully
delivered across various technologies. Driving fiber lines is = pretty
high energy, though, and I think (without a back of = envelope handy),
that that would be far more expensive = than shaping currently is.

still, adding 6 = C to everybody's home router to shape inbound under
heavy = load is pretty costly both in energy and reduced service life.

I=E2=80= =99m intrigued, and care about this topic. A few watts on millions of = devices might at least make some difference. Analyzing where we stand in = terms of energy per byte for different techs, and also what shaping does = to this, might be a place to start.

Other ideas: move queue management into = hardware

I have increasingly = high hopes for P4 and other forms of hardware to
finally = do shaping and queue management right.

https://github.com/ralfkundel/p4-codel/issues/2

Back in the day, I was a huge fan of async = logic, which I first
encountered via caltech's cpu and = later the amulet.

https://en.wikipedia.org/wiki/Asynchronous_circuit#Asynchronous= _CPU

This reduces power consumption = enormously.

There are things that make so much sense as to = seem that they must eventually happen, and this is one of those = things.

power network
equipment with renewables, or = just use the Internet less. :)

I= am glad to see more of the former happening. A recent data center
design in singapore basically needed it's own nuclear power = plant.

At least it doesn=E2=80=99t emit CO2. :) I=E2=80=99m= in the process of trying to make a low-cost solar/battery setup for my = home equipment. It seems that a system that works ~100% of the time can = be much more expensive than one that works ~95% of the time, especially = in central Europe=E2=80=99s winters where cloudy streaks can last weeks, = so I=E2=80=99m probably accepting grid as a backup.

In my case I've always wanted the computing to take place = under the
users fingers, I do not like the centralization = trend we are in today at
all. I like that apple seems to = be leading the way to be putting all
these cool new AI = tools in your own hands.

As for the = latter... I'm using browsers less now (emacs rocks), and
seem to be getting more done.

I=E2=80= =99m with you, only =E2=80=98:s/emacs/vim/g=E2=80=99, but we won=E2=80=99t= start that. :)

= --Apple-Mail=_4C2CAC6D-2824-4C46-BF47-EE9F78BEB33C--