From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-we0-x22b.google.com (mail-we0-x22b.google.com [IPv6:2a00:1450:400c:c03::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 7B95621F118 for ; Tue, 24 Dec 2013 10:46:39 -0800 (PST) Received: by mail-we0-f171.google.com with SMTP id q58so6243446wes.16 for ; Tue, 24 Dec 2013 10:46:37 -0800 (PST) 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=Ng6M6yKtnp5CV1Ewk0Z7YW+5CysUSEC1fKWWGoSGJPc=; b=XVQVgjFItytyKOnIeQGpFKhcitw+LRGfFG9TgSq5G/dGAqPuArCMGeYFG0XmxANgDx /IXfV2DlX5zIXUa+oqAGXgcYtvEXsVil+rFWlF9WTpoHGH2ugEAYVewuKdy+GdCFYf2x 1V66hK4EXzo9YGbzKba6QAMBFacZ9PKdm3J1ohRrFqCMRZCtB8fXtxOBZIHPz3MSWFci 2Z/BX2Du+f+93YSlXs032lUDZIMDnoNAkIt8nQodkG5/7euaoxoRZUKzetQE8nVQpdaH 96bROKO7Nn2W7zlztdlCGknLbo5ByihneWogjoYfveFCL/78I42IM7Dz7mBZM4jJvnuT sJfw== MIME-Version: 1.0 X-Received: by 10.180.10.3 with SMTP id e3mr6937777wib.46.1387910797354; Tue, 24 Dec 2013 10:46:37 -0800 (PST) Received: by 10.217.123.69 with HTTP; Tue, 24 Dec 2013 10:46:37 -0800 (PST) In-Reply-To: References: <56938ED3-0D0A-4269-BCC4-6C8D5BB3BAE8@gmx.de> Date: Tue, 24 Dec 2013 10:46:37 -0800 Message-ID: From: Dave Taht To: Richard O Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "cerowrt-devel@lists.bufferbloat.net" 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 18:46:40 -0000 On Tue, Dec 24, 2013 at 7:26 AM, Richard O wrote: >> 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.3= 0.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.3= 0.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 I should do a lecture on all the useful stuff a practiced eye can see with them. That said, they are terribly noisy and an unpracticed eye often mis-interprets the peaks and valleys. > fq_codel does everything really well, and I had no idea fq_codel can stil= l > 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. No, presently fq_codel does not prioritize diffserv into different htb leav= es. That is the "simple.qos" script doing that. "simplest.qos" doesn't. I have generally found that simplest does a pretty darn good job... but I strongly suspect prioritization at your bandwidth levels is required. Someday, perhaps, we'll pour this into c, and make something faster than htb. I have some thoughts towards doing that.... Please feel free to try simplest.qos in your environment, though. > 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 stumb= led > upon, learning that particular bit of information, but that's all I took > from it. It's good to know I was wrong. I have spent a ton of time correcting websites. (I run a regular google search for bufferbloat but it doesn't catch everything) I wish it were possible to update the lart stuff, like the howtos - they are impossibly outdated and the first hits you get point to things that are massively wrong for todays environments, like wondershaper. Recently I spent some time fixing this script, for example. As posted originally it was just so terribly, terribly wrong. https://wiki.gentoo.org/wiki/Traffic_shaping > 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. No, I always learn things from how people do stuff differently. I ended up writing a bit of a rant on wondershaper while I looking at yours, in a weird sort of result. In your case I have a couple thoughts. I think there is a strong need, particularly at low bandwidths, to have some ability to strongly prioritize a given host's packets (gaming boxes be= ing the most important) and that ability isn't in cero. I can be faulted for mostly testing at 20/4 mbit and above, since that's wh= at I have, and the way the world is going... prioritization counts for much le= ss then, and packetization helps ever more. > (Sorry, I had to remove all the quoted text. It just wouldn't let me post= no > matter what I did.) > > > > > _______________________________________________ > Cerowrt-devel mailing list > Cerowrt-devel@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/cerowrt-devel --=20 Dave T=E4ht Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscribe.= html