[Cerowrt-devel] [Commotion-dev] QoS/packet reordering

[Dan Staples]

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
> <adam.longwill at metamesh.org> 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
>> Commotion-dev at lists.chambana.net
>> 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