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



-- 
Dave Täht
Let's make wifi fast, less jittery and reliable again!

https://plus.google.com/u/0/107942175615993706558/posts/TVX3o84jjmb