[Bloat] one benefit of turning off shaping + fq_codel

[Pete Heist]

> On Nov 23, 2018, at 5:26 PM, Dave Taht <dave at taht.net> wrote:
> 
> Pete Heist <pete at 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”.

Ok, for Intel I see something called “Interrupt Rate Limiting” 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-guides/xl710-x710-performance-tuning-linux-guide.pdf <https://www.intel.com/content/dam/www/public/us/en/documents/reference-guides/xl710-x710-performance-tuning-linux-guide.pdf>). I don’t think that’s exactly it though.

I also wanted to suggest that something “BQL-like” be added to WiFi (I already saw discussion of that in make-wifi-fast), ADSL (I guess that’s mostly proprietary stuff though?) or other techs where it’s 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’t always be fine-grained control over the rate.

> But outbound is not the problem for us from a heat generation standpoint…

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’m 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’t emit CO2. :) I’m 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’s winters where cloudy streaks can last weeks, so I’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.
> 
> As for the latter... I'm using browsers less now (emacs rocks), and
> seem to be getting more done.

I’m with you, only ‘:s/emacs/vim/g’, but we won’t start that. :)

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.bufferbloat.net/pipermail/bloat/attachments/20181124/0db771b6/attachment-0001.html>