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

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

[Dave Taht]

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@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@lists.chambana.net
> 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

Re: [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@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@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

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

[Dave Taht]

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
<danstaples@opentechinstitute.org> 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
>> <adam.longwill@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@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
> _______________________________________________
> Commotion-dev mailing list
> Commotion-dev@lists.chambana.net
> 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

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

[Toke Høiland-Jørgensen]

Dave Taht <dave.taht@gmail.com> writes:

> 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.

sqm-scripts has been backported to Barrier Breaker as well. E.g.
http://downloads.openwrt.org/latest/ar71xx/generic/packages/packages/sqm-scripts_8-2_all.ipk

-Toke