From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from plane.gmane.org (plane.gmane.org [80.91.229.3]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by huchra.bufferbloat.net (Postfix) with ESMTPS id 2D9CF21F1FA for ; Tue, 24 Dec 2013 07:28:22 -0800 (PST) Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1VvTtx-00064y-9n for cerowrt-devel@lists.bufferbloat.net; Tue, 24 Dec 2013 16:28:09 +0100 Received: from CPE-123-211-104-16.lnse4.cha.bigpond.net.au ([123.211.104.16]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 24 Dec 2013 16:28:09 +0100 Received: from rocon46 by CPE-123-211-104-16.lnse4.cha.bigpond.net.au with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 24 Dec 2013 16:28:09 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: cerowrt-devel@lists.bufferbloat.net From: Richard O Date: Tue, 24 Dec 2013 15:26:25 +0000 (UTC) Message-ID: References: <56938ED3-0D0A-4269-BCC4-6C8D5BB3BAE8@gmx.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: sea.gmane.org User-Agent: Loom/3.14 (http://gmane.org/) X-Loom-IP: 123.211.104.16 (Mozilla/5.0 (Windows NT 6.2; WOW64; rv:26.0) Gecko/20100101 Firefox/26.0) Subject: Re: [Cerowrt-devel] Cero 3.10.24-5 no longer supports multiple AQMs? 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, 24 Dec 2013 15:28:23 -0000 > Dave Taht gmail.com> writes: > > > Just a pair of quick comments on something you said below. I'll look > over your scripts later. > > There is PLENTY of sense in shaping inbound traffic. Inbound is the > bulk of the problem in many cases - verizon has 300ms of inbound > buffering in their 25/25mbit service, and comcast often well over a > second on their 25Mbit/4. (and often over a second on outbound but the > new modem I've been testing is only about 200ms. But the bulk of the > delay is on inbound, by far) > > comcast shaped only on inbound: > > > http://snapon.lab.bufferbloat.net/~cero2/armory.com/3.10.24.5/oneway/149.20.63.30.rrul-ethernet-ecn.svg > > comcast unshaped entirely exhibits almost 2 seconds of delay before it > starts dropping packets. > > > http://snapon.lab.bufferbloat.net/~cero2/armory.com/unshaped/149.20.63.30.rrul-comcast_unshaped.svg > > UGH! This is the kind of performance cable users have to deal with! I > hope the CMTS folk get their act together soon. > > And the normal glorious post > whatever-the-heck-we're-going-to-call-aqm-scripts-ceroshaper result: > > > > http://snapon.lab.bufferbloat.net/~cero2/armory.com/3.10.24.5/149.20.63.30.rrul_noclassification-ethernet-ecn.svg > > So... a lot of people keep insisting that "shaping inbound doesn't > work" on the client device, and it just aint true. I had hoped to just > be able to fix the cable modems in docsis 3.1, but that isn't going to > be what happens, sadly. > > Sure: a primitive use of a policer doesn't work well (see wondershaper > result below), but attaching htb + fq_codel on ingress works fine. > Perhaps we need to collect a wide swath of results from tools like > netanalyzer, too? with inbound and outbound enabled/disabled in > combination? > > What might have caused confusion? is that I generally enable ECN on > inbound so that ECN compliant streams don't get their packets dropped, > but marked, when it's time to slow down. (Very little traffic > is ECN marked.) > > Anyway, I recently went through a round of tests of 2.10.24, realizing > only later that the instruction trap error was skewing the data on > some tests. There are some new results. > > This is wondershaper on a 25Mbit/4Mbit comcast service. The inbound > policer drops far too many packets to get even half the allocated > bandwidth. (Wondershaper has many other problems. It needs to die!) > > > > http://snapon.lab.bufferbloat.net/~cero2/armory.com/3.10.24.5/149.20.63.30.rrul-wondershaper.svg > > I do not know to what extent DPI is used to mess with torrents, but I > got a good 50 client download going of ubuntu and still had very good > performance for normal tcp, and web pages are pretty good, too. > > http://snapon.lab.bufferbloat.net/~cero2/armory.com/with_torrent/ipv4-2.svg > > (as always these dirs contain far more data than just what I'm cherry > picking above, notably a bunch of simpler tcp up/down/bidir plots. > feel free to move around) > > Wow, those RRUL graphs show some interesting stuff. It's cool to know fq_codel does everything really well, and I had no idea fq_codel can still differentiate between UDP EF traffic and UDP BE traffic w/o having to prioritize them into different htb leafs first. I guess that kinda makes my classification rules redundant, I suppose. Anyway, I got the idea shaping inbound traffic didn't do much while I was looking up about what Cero and fq_codel was about waaay back when I was deciding on whether I should try it out. I'm not sure which forum I stumbled upon, learning that particular bit of information, but that's all I took from it. It's good to know I was wrong. Also, you don't have to bother looking at my script. Everything works as well as I could hope for and I'm sure you have much more important things to be focused on. Again, thanks for taking the time to help out a smuck like me. (Sorry, I had to remove all the quoted text. It just wouldn't let me post no matter what I did.)