From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (Client CN "mout.gmx.net", Issuer "TeleSec ServerPass DE-1" (verified OK)) by huchra.bufferbloat.net (Postfix) with ESMTPS id 6E18621F19A for ; Wed, 11 Dec 2013 02:45:40 -0800 (PST) Received: from [172.30.42.112] ([87.150.22.181]) by mail.gmx.com (mrgmx002) with ESMTPSA (Nemesis) id 0MXIov-1W5G8z3mS5-00WI7i for ; Wed, 11 Dec 2013 11:45:37 +0100 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Sebastian Moeller In-Reply-To: Date: Wed, 11 Dec 2013 11:44:39 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20131203222559.GV8066@einstein.kenyonralph.com> <7ieh5pew2d.wl%jch@pps.univ-paris-diderot.fr> <13A953B7-EDAF-4767-8C9B-B05D4447D964@gmx.de> To: Dave Taht X-Mailer: Apple Mail (2.1510) X-Provags-ID: V03:K0:WQ2Od9O33LlLQRFHoHwh2kmSDcDNVlwAK8xvTdZEe5IYZlvtxV5 JP4nsVAHxvwXNt7ZegjnMbrvFRxKKdQcNQiCrFiGVU2TcFoymfBjC4UIpJ+dwMHZCW+H5+r /eLSGuaDE9EFdfgRqEnPqPea3tU6jERgdB3++wkHSpn2uRoUpKxf98vR+G5sEt5BAZBDvuu HmcrHGREfkn8pdrHsGVcg== Cc: bloat , Juliusz Chroboczek Subject: Re: [Bloat] curious..... X-BeenThere: bloat@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list List-Id: General list for discussing Bufferbloat List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Dec 2013 10:45:40 -0000 Hi Dave, On Dec 10, 2013, at 20:05 , Dave Taht wrote: > I am here: >=20 > http://conferences.sigcomm.org/co-next/2013/program.html >=20 > this week, so expect emails from me to be sparse to non-existent. Santa Barbara, how nice. Since we left California this spring I = started to miss the Pacific; funny since we rarely went to the beach. = Anyway I envy you :) >=20 > On Sat, Dec 7, 2013 at 3:24 AM, Sebastian Moeller = wrote: >> Hi Dave, >>=20 >>=20 >> On Dec 6, 2013, at 19:15 , Dave Taht wrote: >>=20 >>> On Fri, Dec 6, 2013 at 9:19 AM, Juliusz Chroboczek >>> wrote: >>>>> I note that openwrt's qos-scripts still do not do ipv6 properly, = and I think >>>>> cerowrt's aqm system is better in most respects, and it's easy to >>>>> include on an openwrt system. >>>>=20 >>>> Perhaps you should push your system to OpenWRT? >>>=20 >>> There is still some work going on to streamline the gui. there are >>> less features in the aqm-scripts for >>> prioritizing packet types than qos-scripts. >>=20 >> Do you think these additional features are essential? I assume = that openwork would not immediately drop their QOS packet so "AQM/SQM" = and QOS will live together for some time, so having slightly different = features might still be okay. >=20 > Most people like knobs. I don't - most people also have a tendency to > turn up everything to 11. So it is perhaps too idealistic of me to try > and come up with something that handles the bulk of shaping needs with > no knobs whatsoever. I guess I like knobs, they give me a warm fuzzy feeling; I do = prefer not having to touch those knobs though :) >=20 > I would certainly like openwrt folk to fix qos-scripts to work right > with ipv6 in particular, but the connection tracking element is > required in the current qos-scripts, and substantial changes to how it > works would need to be made. >=20 > So offering sqm-scripts as an alternative in the main distro would be = good, > especially for ipv6 users, but also because I do think it's generally = better. At least in the past there were alternatives to QOS in OpenWRT, = I am not sure whether these survived to recent restructuring though. >=20 >=20 >>> I just had to come up with >>> a way to disable it at high (> 80 mbit) rates on incoming traffic = (not >>> enough cpu in cerowrt), so I'd like it to run faster, maybe using = drr >>> in that case, or something like what free.fr uses... >>>=20 >>> And there are actually two aqm/packet scheduling shapers in there (a >>> simple 1 tier and a 3 tier one) >>=20 >> What is your opinion, should we default to the single tier = version or the 3 tier version? >=20 > I actually get such great results from simplest.qos on normal traffic, > *on systems running at 5Mbit+* even with bit torrent, that I'm tempted > to recommend that rather than the three tier system. Ah, I guess I should actually try to test how this works with my = VoIP. What I like about the 3 tier system is that if the need arises it = will be relatively simple to control the latency of specific traffic by = marking it appropriately. I guess it is a belts and suspender thing. I = have a question though; with simplest.qos we still use HTB svn though = there is no hierarchy, so maybe we could switch to TBF (assuming TBF is = actually less computationally demanding than HTB)? > But that breaks > with tradition too much, and ietfers > are off specifying 1024 different behaviors based on the 8 bits of the > tos field, This sounds quite complicated, and I am unsure whether that is = really required for a home router :) > so I fear that only 3 bins is controversial, and 1 bin, > anathema. >=20 > Below that prioritization is truly needed and helps, and there > certainly is a vague zone between 5 and 30MB on the traffic types I > see in the home. So 3 bins > seems to continue to make sense in the general case. Ah, okay, so would you agree that simple.qos then should be the = default? >=20 > Recently I had some correspondence with the person at free that > deployed fq_codel, who has deployed *at scale* a three tier system > similar to cero's but it runs at line rate w/adsl, and combines prio, > drr, and fq_codel. It's running on the "revolution V6" box. There was > an interesting short algo to increase target at bandwidths below > 5mbit, which seems to make sense. To allow at least a few packets worth of queueing? >=20 > Does anyone here have free.fr access and can do a rrul measurement? Sorry wrong country, I have to pass. >=20 > And in terms of research still ongoing I'd like (someone) to take a > hard look at gargoyles' "acc". >=20 >>> , and it supports a variety of >>> aqm/scheduling algorithms, not just fq_codel, which is there for = the >>> research but will confuse the end users=85 >>=20 >> I guess it should be relatively easy to hide this under the = control of a "I know what I am doing give me all the knobs to play with" = checkbox with a scary name, say "research"=85 :) >=20 > Sure. "Advanced". Done, okay, this was easy :) Since I am still on 3.10.18-1 I = will first upgrade to the most recent one to see the changes you made to = the AQM code=85 Also this will allow me to test my hypothesis about = sysupgrade being affected by mount-utils.=20 >=20 >> Question, I tried to send you a version of aqm.lua that hides = the detailed link layer fields in the GUI if none is selected as link = layer adaptation mechanism did that ever reach you (I have some issues = with my mailer so it might not have made it out of my system for good)? = But in the same vain, hiding "Queueing discipline" and "Queue setup = script" should be simple=85 >=20 > I saw it whiz by as I was doing a zillion other things that week. > Sorry! There were two other patches I really wanted in the that > release - the fix to TSQ and pie v4. The first was put into 3.10.23, > and the second hit netdev a few days ago. If I understand it correctly the TSQ patch should only affect = traffic that terminates at the router; so it might affect netsurf = sessions to the router but should not affect normal routing, or am I = wrong here? >=20 > I am limited to working on cero on sundays right now so I can > incorporate your latest patch if it arrives by sunday morning. I should be able to pull this off, even though I am under a = deadline right now. >=20 >>=20 >>> and I am not happy with >>> "aqm" at a word, because the packet scheduling part counts for a = LOT, >>> so i'd rename it to sqm or someting like that. >>=20 >> What about the long and verbose "Latency and Bandwidth = Control" or something else that talks about the "benefit" to the user? >=20 > That's better. I agree that makes sense to accentuate the positives. >=20 > "Latency and Bandwidth Optimization"? LBO? Do you want to rename every occurrence of AQM or would you be = happy with just changing the labels on the webpage? Since that is easy I = will fold this into my modification... >=20 >>>=20 >>> So I'd argue it needs some love. And a solid set of requirements = that >>> it meets before it is as standardized as, say, wondershaper is. And = if >>> it got that standardized, I think it would run a heck of a lot = faster >>> if it got poured into C. >>=20 >> Just curious, isn't the kernel doing all the work for us? I = ,foolishly?, assumed that the script is just configuring the kernel and = since this is done rarely why would we bother about the run time=85 >=20 > HTB's code is highly flexible and highly inefficient . >=20 > tc is an incredibly flexible construction set for discs. This also > comes at the expense of inefficiency as well. Yeah, but we only run tc while setting things up and even if it = would take a minute we would not care? >=20 > One of the points of fq_codel is it combines a drr-like algorithm with > the codel algorithm in the same code so, for example, we get buffer > sizes much more under control than if we were to use > tc to combine, say DRR + codel or DRR + pie (or QFQ + pie). And there > is a great deal of synergy between several characteristics of the two > basic algorithms. >=20 > So I keep hoping with a successor to aqm-scripts, call it "cake", that > we can make something even better - that scales to 200+mbit on current > hardware, uses less memory, groks diffserv and packet prioritization > sanely, makes your networks scale farther, and will make your teeth > whiter and improve your sex life. Ah, I see, also if included in the kernel this actually would = have a fighting chance to make it into the firmware of commercial = routers and help people who have no time/fun to tinker with things. >=20 >>> However it is pretty stable and could definitely use more eyeballs, >>> and it works right with ipv6 and seems better than qos-scripts on = most >>> benchmarks... so I'll ask the openwrt folk if they want it upstream. >>>=20 >>> In the interim, existing openwrt users can add ceropackages-3.3 into >>> their feeds. >>>=20 >>> And incorporate it into their build with >>>=20 >>> ./scripts feeds install aqm-scripts luci-app-aqm >>=20 >> Note: people should at least disable openwork's QOS before = activating "AQM"; or should we teach AQM to either disable qos on = activation or at least warn the user about a potential conflict. I = assume people will want to compare the performance of both=85 >=20 > Yes, the two packages should either be mutually exclusive or aware of > each other. Mmmh, I see qos-scripts is still part of cero's packages, I = guess I will try figuring out whether/how that would work. >=20 >> best >> Sebastian >>=20 >>>=20 >>>=20 >>>=20 >>>> -- Juliusz >>>=20 >>>=20 >>>=20 >>> -- >>> Dave T=E4ht >>>=20 >>> Fixing bufferbloat with cerowrt: = http://www.teklibre.com/cerowrt/subscribe.html >>> _______________________________________________ >>> Bloat mailing list >>> Bloat@lists.bufferbloat.net >>> https://lists.bufferbloat.net/listinfo/bloat >>=20 >=20 >=20 >=20 > --=20 > Dave T=E4ht >=20 > Fixing bufferbloat with cerowrt: = http://www.teklibre.com/cerowrt/subscribe.html