A damp discussion of network queuing
A damp discussion of network queuing
Posted Oct 18, 2014 13:09 UTC (Sat) by nix (subscriber, #2304)In reply to: A damp discussion of network queuing by mtaht
Parent article: A damp discussion of network queuing
So... any scripting? (Not that I can really use it yet, since as mentioned previously my firewall's NIC doesn't have BQL support yet -- but in future, it would be nice if I could arrange for my networking gear to not be bufferbloated to death. I think this means fixing my firewall and ditching the ADSL routers it's connected to and replacing them with cerowrt-capable routers or something like that -- which would be beneficial anyway, since I'd be able to have them reliably communicate the state of the ADSL link to the firewall, which could pull up/down the components of the multipath route appropriately. Right now I'm relying on horrible hacks like looking at passing inbound packets and *hoping* they come from the Internet rather than, say, the ADSL router's administrative interface, and falling back on periodic pings if none are seen... all quite horrible.)
Posted Oct 21, 2014 4:57 UTC (Tue)
by dlang (guest, #313)
[Link] (7 responses)
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.
Posted Oct 21, 2014 16:27 UTC (Tue)
by nix (subscriber, #2304)
[Link] (6 responses)
I used to use wondershaper for this but it's completely bitrotted and doesn't work at all any more.
Posted Oct 22, 2014 4:16 UTC (Wed)
by dlang (guest, #313)
[Link] (5 responses)
The difficulty for outbound traffic is in automating the discovery of what you're available bandwith is.
Posted May 15, 2015 0:23 UTC (Fri)
by nix (subscriber, #2304)
[Link] (4 responses)
commit 92bf200881d978bc3c6a290991ae1f9ddc7b5411
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>
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.
Posted May 16, 2015 17:55 UTC (Sat)
by mtaht (subscriber, #11087)
[Link] (3 responses)
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)
Posted May 19, 2015 19:23 UTC (Tue)
by nix (subscriber, #2304)
[Link] (2 responses)
Thank you for a most excellent qdisc, anyway!
Posted May 19, 2015 19:40 UTC (Tue)
by dlang (guest, #313)
[Link] (1 responses)
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.
Posted May 20, 2015 10:15 UTC (Wed)
by paulj (subscriber, #341)
[Link]
A damp discussion of network queuing
A damp discussion of network queuing
A damp discussion of network queuing
A damp discussion of network queuing
Author: Tino Reichardt <milky-kernel@mcmilk.de>
Date: Tue Feb 24 10:28:01 2015 -0800
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>
A damp discussion of network queuing
A damp discussion of network queuing
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? :(
A damp discussion of network queuing
A damp discussion of network queuing