From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ob0-x22b.google.com (mail-ob0-x22b.google.com [IPv6:2607:f8b0:4003:c01::22b]) (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 4060D21F23A for ; Tue, 31 Mar 2015 08:12:07 -0700 (PDT) Received: by obbec2 with SMTP id ec2so30857160obb.3 for ; Tue, 31 Mar 2015 08:12:07 -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=xtQZOHdYGO793ngNWKyqSJGC5QaKvXtPbAMfcA6pK9o=; b=mCiwVP5/gq7D5/RhZDx4rO/p8GD/FghomUHbtBXf0fCPme3RPyyd/7Ap0YeQylgEkH fwIZ9y+b4t0ZCBly1you1enfy1UUQb++EMZrh3qfoNTUJ2oYmDc4+kdVZA24n52aSaM9 mlRO9PfT2wsvJ5kv+PrLVR8tOxb7+/ehsLwXuYlQlDx3RLsDNu1Y4hAEoxcQiv7jZS9P SUaM8gGXPsp7U063OyOZhoDRMgPXv6Kj3XMT+snDphKQ7TaNkRq6BXh8wLoxvLI6ZK0e NbHfkYVKE4t/2GLkCofdZM86dBuzXq1qmqGPgLoJxLiIgpgOaQ6gbt9qpKmQiu0AYBtd nWLg== MIME-Version: 1.0 X-Received: by 10.182.144.136 with SMTP id sm8mr33690459obb.63.1427814710779; Tue, 31 Mar 2015 08:11:50 -0700 (PDT) Received: by 10.202.51.66 with HTTP; Tue, 31 Mar 2015 08:11:50 -0700 (PDT) In-Reply-To: References: Date: Tue, 31 Mar 2015 08:11:50 -0700 Message-ID: From: Dave Taht To: Adam Longwill , "cerowrt-devel@lists.bufferbloat.net" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: commotion-discuss , Commotion Development List 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:12:36 -0000 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 variabl= e. 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-comcas= ts-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-buffer= bloat=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-script= s 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 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 an= d > 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 WDR3= 600 > is connected to the host's gateway. > > Ideally, the hosts use the WDR3600 as their primary router because then w= e > 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 > --=20 Dave T=C3=A4ht Let's make wifi fast, less jittery and reliable again! https://plus.google.com/u/0/107942175615993706558/posts/TVX3o84jjmb