Barrier breaker's qos-scripts leverages fq_codel also. :) however it is broken in one regard - it doesn't work at all with ipv6. If you can live with that (I can't, comcast ipv6 is now everywhere) - use it.
On Tue, Mar 31, 2015 at 8:16 AM, Dan Staples <[email protected]> wrote: > I'm not sure what's available in Attitude Adjustment, but I worked with some > folks to set up QoS on a network running Barrier Breaker recently, using the > built-in QoS web user interface, and it turned out quite successful. There > was a gateway WDR4300 that had two separate VLANs, one of which needed to get > priority for its traffic. The switch on the WDR4300 was split between the two > VLANS, each of which had a wireless access point connected to it via ethernet. > > We ran iperf on both VLANs simultaneously, connecting to our server on the > internet, and the priority VLAN was able to push substantially more traffic. > > Dan > > On 03/31/2015 11:11 AM, Dave Taht wrote: >> What we did in cerowrt, openwrt, and the eff project was first >> establish a bound for the total available bandwidth on the link using >> netperf based test tools like the cerowrt-scripts[1] or >> netperf-wrapper once, and then using sqm-scripts on that link with >> that setting, and then (if desired) also use sqm-scripts on the guest >> link with a lower setting. (in both cases using htb + fq_codel). >> >> It works, so long as your isp link is more or less constant and not variable. >> It still requires manually running the test, but could be automated further. >> >> However I MUST note that the effects of link-sharing with many users >> are nearly invisible overall if you just fix your link to the isp to >> have fq/aqm and low latency. >> >> The bufferbloat-compelling reasons to setup every link to your isp >> with locally fq_codel'd managed bandwidth are here: >> >> Cable: >> http://burntchrome.blogspot.com/2014/05/fixing-bufferbloat-on-comcasts-blast.html >> >> http://snapon.lab.bufferbloat.net/~cero2/jimreisert/results.html >> >> Fiber: http://zlkj.in/fiber-sqm >> >> DSL: >> http://planet.ipfire.org/post/ipfire-2-13-tech-preview-fighting-bufferbloat >> >> There is no way a shared link will eat all your bandwidth with this >> stuff in place. And it is NOT bandwidth, but mostly the induced >> latency people "feel" on today's system rather than "bandwidth" >> lossage, on shared links. >> >> and you can certainly apply the sqm scripts on the meshy link again >> at a lower rate if you really must. >> >> try 'em. >> >> sqm-scripts is in chaos calmer. It has a complete gui allowing you to >> set things on a per device basis. >> >> https://github.com/dtaht/ceropackages-3.10/tree/master/utils/cerowrt-scripts >> >> https://github.com/tohojo/netperf-wrapper >> >> >> >> On Tue, Mar 31, 2015 at 6:23 AM, Adam Longwill >> <[email protected]> wrote: >>> Over here at PittMesh we're trying to implement something we describe as >>> "relative QoS" or "packet reordering" and we're not coming up with much. >>> >>> Basically, we want to ensure bandwidth donors don't attach to the mesh and >>> then have all their bandwidth eaten up. >>> >>> We have introduced a 2 router system: We deploy one Rocket outside that >>> broadcasts into the street and mesh it over ethernet to a wdr3600 inside >>> that allows people to access PittMesh from their home/business. THAT WDR3600 >>> is connected to the host's gateway. >>> >>> Ideally, the hosts use the WDR3600 as their primary router because then we >>> can implement tools that should prefer Port 2-4 over port 1, the PittMesh >>> port. >>> >>> The problem is, we haven't found a way to do this very well. >>> >>> We can implement port-based QoS-- but as far as we can tell we have to >>> define a limit to the bandwidth-- which we don't necessarily KNOW. >>> >>> What we want to do is just give priority to packets on ports 2-3. Meaning, >>> they get processed and moved first, regardless of any other factor. Port 1's >>> packets have to wait until there is a break in the packets for ports 2-3. >>> >>> Does anyone have any ideas on how to implement this? >>> >>> Thanks >>> >>> _______________________________________________ >>> Commotion-dev mailing list >>> [email protected] >>> https://lists.chambana.net/mailman/listinfo/commotion-dev >>> >> >> >> > > -- > Dan Staples > > Open Technology Institute > https://commotionwireless.net > OpenPGP key: http://disman.tl/pgp.asc > Fingerprint: 2480 095D 4B16 436F 35AB 7305 F670 74ED BD86 43A9 > _______________________________________________ > Commotion-dev mailing list > [email protected] > https://lists.chambana.net/mailman/listinfo/commotion-dev -- Dave Täht Let's make wifi fast, less jittery and reliable again! https://plus.google.com/u/0/107942175615993706558/posts/TVX3o84jjmb _______________________________________________ Cerowrt-devel mailing list [email protected] https://lists.bufferbloat.net/listinfo/cerowrt-devel
