A damp discussion of network queuing

Posted Oct 21, 2014 4:57 UTC (Tue) by dlang (guest, #313)
In reply to: A damp discussion of network queuing by nix
Parent article: A damp discussion of network queuing

> One thing I've been wondering about -- does anyone actually have a bunch of scripts that set things up properly?

What are you trying to setup? fq_codel and BQL can be setup at compile time and need no scripts to function.

Cerowrt has additional configuration scripts for other benefits (artificially limiting outbound traffic to make this box the bottleneck rather than allowing an upstream router to be the bottleneck, and working to limit inbound bandwidth usage), these are the things that are hard to setup.

But just enabling fq_codel helps, as does BQL, and they work well when combined.

A damp discussion of network queuing

Posted Oct 21, 2014 16:27 UTC (Tue) by nix (subscriber, #2304) [Link] (6 responses)

It's basically the latter, the 'make us the bottleneck', with the extra fun that I'm using line bonding, my lines are somewhat different speeds, and the outbound interface used is basically random (determined by a hash of the src/dst/port triplet IIRC) while the incoming is evenly distributed between the lines)...

I used to use wondershaper for this but it's completely bitrotted and doesn't work at all any more.

A damp discussion of network queuing

Posted Oct 22, 2014 4:16 UTC (Wed) by dlang (guest, #313) [Link] (5 responses)

I think the right thing to do nowdays is to use the kernel HTB support to define the bandwidth of each connection. If you limit the throughput for each connection, I believe that fq_codel will end up doing the "right thing" for you.

The difficulty for outbound traffic is in automating the discovery of what you're available bandwith is.

A damp discussion of network queuing

Posted May 15, 2015 0:23 UTC (Fri) by nix (subscriber, #2304) [Link] (4 responses)

FYI, the net-next tree now has this commit:

commit 92bf200881d978bc3c6a290991ae1f9ddc7b5411
Author: Tino Reichardt <milky-kernel@mcmilk.de>
Date: Tue Feb 24 10:28:01 2015 -0800

net: via-rhine: add BQL support

Add Byte Queue Limits (BQL) support to via-rhine driver.

[edumazet] tweaked patch and changed TX_RING_SIZE from 16 to 64

Signed-off-by: Tino Reichardt <milky-kernel@mcmilk.de>
Tested-by: Jamie Gloudon <jamie.gloudon@gmail.com>
Signed-off-by: Eric Dumazet <edumazet@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

So those of us with Rhine-based NICs finally have access to the codel and fq_codel goodness. And what goodness! It's as zero-configuration as advertised: with no configuration at all, even without any outbound traffic shaping and with unaltered probably bloated-as-hell queues inside the ADSL modems, all my bufferbloat symptoms have silently vanished and my line is smooth and usable under load, with ping times only a few ms up on a saturated line as on an idle one. Now that's a *nice* qdisc!

mtaht et al have done a really really *really* good job here. I can see why every distro is jumping on this as fast as they can.

A damp discussion of network queuing

Posted May 16, 2015 17:55 UTC (Sat) by mtaht (subscriber, #11087) [Link] (3 responses)

I am glad to see the rhine patches finally landed. There were a few popular devices used as firewalls that used that chipset.

However I must note that your excellent result was probably due to fq_codel taking advantage of hardware flow control exerted by the DSL modem, which then is seen by fq_codel as delay and managed appropriately, where pfifo_fast would just keep buffering until it hits the packet limit.

Most edge devices today do not exert hardware flow control. Certainly I feel that {dsl,cable}modems should use hardware flow control! It is a sane signal that can also be aware of congestion on media. But nearly everybody put switches, rather than ethernet devices in the path here, over the past 5 years, and lost that capability. So we have generally have had to use software rate limiting (sqm-scripts) to succeed here... or to push for more hardware flow control (or smarter modems)

A damp discussion of network queuing

Posted May 19, 2015 19:23 UTC (Tue) by nix (subscriber, #2304) [Link] (2 responses)

I am glad to see the rhine patches finally landed. There were a few popular devices used as firewalls that used that chipset.

Indeed there were (though I don't know if the Soekris net5501 I use could ever be defined as 'popular' except among the geekiest crowd and those who want to network up oil rigs.)

However I must note that your excellent result was probably due to fq_codel taking advantage of hardware flow control exerted by the DSL modem

That's what I presumed. Nothing else could explain how it managed to figure out my ADSL bandwidth given the total absence of any other way to detect it.

But nearly everybody put switches, rather than ethernet devices in the path here, over the past 5 years, and lost that capability.

Yeah. I guess if your modem has only one port, and you don't have a dedicated multi-port firewall box, that's all you can really do... I wonder: are the very common 'four-port ADSL modems' actually an ADSL modem and a switch in the same box? If so, I guess they're eschewing flow control too, right? :(

Thank you for a most excellent qdisc, anyway!

A damp discussion of network queuing

Posted May 19, 2015 19:40 UTC (Tue) by dlang (guest, #313) [Link] (1 responses)

> I wonder: are the very common 'four-port ADSL modems' actually an ADSL modem and a switch in the same box?

they are commonly a system running linux with an ADSL modem and an ethernet connected to a 4-port switch.

Unfortunately they usually are using a binary driver for the DSL side, so getting them supported by OpenWRT is hard :-(

If they were based on the current OpenWRT instead of a several-year-old one, they would be using fw_codel by default.

A damp discussion of network queuing

Posted May 20, 2015 10:15 UTC (Wed) by paulj (subscriber, #341) [Link]

There is one family of them that has a free software driver, at least on the Linux kernel side. The Lantiq SoCs:

http://wiki.openwrt.org/doc/hardware/soc/soc.lantiq