From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ob0-x22a.google.com (mail-ob0-x22a.google.com [IPv6:2607:f8b0:4003:c01::22a]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by huchra.bufferbloat.net (Postfix) with ESMTPS id CC62D21F240 for ; Tue, 31 Mar 2015 08:38:52 -0700 (PDT) Received: by obbec2 with SMTP id ec2so32088752obb.3 for ; Tue, 31 Mar 2015 08:38:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=e5seYceYhciKf6RgetToI8Cu+fXuev9j6K3YXWy1xV4=; b=F4ggTmD+kOrhOWSF9WL4r7gXhZdVlamPpNDFMaAttNHZ5GauseseDacYZ7GRiKsq0s xurOIAA5cMerXjF0QvW7FY9obMpA9QgUaONCOJFAdYd82o8YAIl+pnAnv15XQq8TbPun IZLNgmEn1k0temkcLjzwAwo2MQ/OCDUy03rGrvEzi+hn1713N0YWLgSasbDJAQ0+DrIz 94DTpxjZTPzq1x3pmq7X245MNksN60hWlRTDB6V9+oNLBOiHV12mUE1wVGoL0DMenffo NMAKK3I35aPqWCWmY+aslZW/7xamom0iI3xkZDGnxbm7v8BXoegIvf5IGEFlnL/kGDUb d9vA== MIME-Version: 1.0 X-Received: by 10.60.123.83 with SMTP id ly19mr33600000oeb.8.1427816312278; Tue, 31 Mar 2015 08:38:32 -0700 (PDT) Received: by 10.202.51.66 with HTTP; Tue, 31 Mar 2015 08:38:32 -0700 (PDT) In-Reply-To: <551ABA61.6010403@opentechinstitute.org> References: <551ABA61.6010403@opentechinstitute.org> Date: Tue, 31 Mar 2015 08:38:32 -0700 Message-ID: From: Dave Taht To: Dan Staples Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: commotion-discuss , Commotion Development List , "cerowrt-devel@lists.bufferbloat.net" Subject: Re: [Cerowrt-devel] [Commotion-dev] QoS/packet reordering X-BeenThere: cerowrt-devel@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list List-Id: Development issues regarding the cerowrt test router project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Mar 2015 15:39:21 -0000 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 wrote: > I'm not sure what's available in Attitude Adjustment, but I worked with s= ome folks to set up QoS on a network running Barrier Breaker recently, usin= g 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 neede= d to get priority for its traffic. The switch on the WDR4300 was split betw= een the two VLANS, each of which had a wireless access point connected to i= t via ethernet. > > We ran iperf on both VLANs simultaneously, connecting to our server on th= e internet, and the priority VLAN was able to push substantially more traff= ic. > > 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 vari= able. >> It still requires manually running the test, but could be automated furt= her. >> >> 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-com= casts-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-buf= ferbloat=EF=BB=BF >> >> 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-scr= ipts >> >> https://github.com/tohojo/netperf-wrapper >> >> >> >> On Tue, Mar 31, 2015 at 6:23 AM, Adam Longwill >> wrote: >>> Over here at PittMesh we're trying to implement something we describe a= s >>> "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 insid= e >>> that allows people to access PittMesh from their home/business. THAT WD= R3600 >>> 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 PittMe= sh >>> 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. Meani= ng, >>> they get processed and moved first, regardless of any other factor. Por= t 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 --=20 Dave T=C3=A4ht Let's make wifi fast, less jittery and reliable again! https://plus.google.com/u/0/107942175615993706558/posts/TVX3o84jjmb