From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by huchra.bufferbloat.net (Postfix) with SMTP id 50C8D200629 for ; Wed, 1 Feb 2012 11:17:23 -0800 (PST) Received: (qmail invoked by alias); 01 Feb 2012 19:17:20 -0000 Received: from tsaolab-fw.caltech.edu (EHLO [192.168.50.18]) [131.215.9.89] by mail.gmx.net (mp031) with SMTP; 01 Feb 2012 20:17:20 +0100 X-Authenticated: #24211782 X-Provags-ID: V01U2FsdGVkX1+3he9Pn8q3VdCQRxqDS0DZmW9FBieiIRlknRPO6i /QgFpInZLXkYwi Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=windows-1252 From: Sebastian Moeller In-Reply-To: Date: Wed, 1 Feb 2012 11:17:18 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <4B1F748F-DD88-4498-8F9D-0C27E01721AE@gmx.de> References: To: Dave Taht X-Mailer: Apple Mail (2.1251.1) X-Y-GMX-Trusted: 0 Cc: cerowrt-devel@lists.bufferbloat.net, bloat Subject: Re: [Bloat] Testing Queue models 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, 01 Feb 2012 19:17:24 -0000 Hi Dave, On Feb 1, 2012, at 10:17 AM, Dave Taht wrote: > can you reply to the lists for details like this? Sorry, forgot to reply all, I hope I fixed it now. >=20 > The ADSL-shaper work that went into the stab option was pretty > fundamental, and needed. >=20 > A) Fix openwrt's shaper to be more right for their distro (which > doesn't have SFQRED nor QFQ) Okay, I will try to coordinate with upstream if that can be = somehow included in vanilla openwork (even though I hope that vanilla = will switch to your new scripts soon :) ) This might take a while, but = It is on my todo list, But if vanilla sticks to its old shaper and = shaper setup scripts than sharing this with cerowrt is going to be only = in idea not in implementation... > B) Fix it to be right on cerowrt This is I guess were I need your guidance (and where I actually = need to switch to the most recent cerowrt first, I am still on ocean = city=85) > C) Clean up the web interfaces to make it obvious that DSL can be = 'special' That is beyond my capabilities, I am a scripting king of person = (I might give it a try but no ETA, ...) >=20 > But first up, is models and analysis. Measure twice, cut once=85. Yeah, I guess I will try the current cerowrt, hack stab inside = and see whether it still makes a difference (I assume it will), please = just ignore me until then=85 >=20 > I'm puzzled about your mtu setting, however=85 from tc-stab man page: "mtu maximum packet size we create size table for, assumed 2048 if not = specified explicitly" so this does not affect the real mtu. Opencoding this default was meant = as a reminder for me to go back and try understanding and implement the = following part of the man page: "For ATM size tables, 16~bytes sized slots are perfectly enough. The = default values of mtu and tsize create 4~bytes sized slots." But I did not get around to that... Best Sebastian >=20 > On Wed, Feb 1, 2012 at 6:13 PM, Sebastian Moeller = wrote: >> Hi Dave, >>=20 >> cool work! >>=20 >> One thing I noticed (ocean city on ADSL over ATM) is the I really = needed to use tc's stab option in combination with the default openwork = shaper to get latencies down to a useful level. >> My crude hack was adding: >> tc_stab_string=3D"stab overhead 18 mtu 2048 mpu 53 linklayer atm" >> to generate.sh; and then modifying the addition of root disc like the = following >> tc qdisc add dev $dev root handle 1: ${tc_stab_string} hfsc default = ${class_default}0 >> Then I only needed to reduce the uplink and downlink speed marginally = (5%) and got good and stable ping latencies even in the lieu of massive = uploads and opening 100 browser tabs at the same time. Without the stab = option I had to reduce nominal speeds to around 65%-70% of the line rate = and still got worse ping latencies than with the stab option. >> Obviously the exact invocation of the stab depends on a number = of factors, like the encapsulation used; since I do not know a generic = way of discovering those automatically (unless the del modem is part of = the router) I think this needs to be user editable... >>=20 >> So it would be sweet if there would be an easy way (either per editor = or GUI) to actually include stab options into the shaper to deal with = this DSL over ATM specific issue. >>=20 >>=20 >> Thanks for deflating the buffers and rescuing decent latencies=85 >>=20 >> Best >> Sebastian >>=20 >>=20 >> On Feb 1, 2012, at 9:12 AM, Dave Taht wrote: >>=20 >>> Now that I have BQL and the new SFQ, ARED, and SFQRED working in >>> cerowrt, I have been working on modeling the behavior of existing >>> shapers (wshaper, openwrt, sfqred, and something more torrent-proof >>> that doesn't have a name yet) >>>=20 >>> There are several things that will get in the way of doing it well = at >>> the present time, and I hope to evolve towards something that works >>> well in nearly all cases. For purposes of this discussion I'll use a >>> few abbreviations. >>>=20 >>> "u" =3D user >>> "d" =3D device >>> "f" =3D flow >>>=20 >>> Some general notes: >>>=20 >>> Accurately determining uplink bandwidth is something that no tool = does >>> quite right today, and even then uplink bandwidth can be dynamic >>> (notably on cable). Van and Kathie are working on something that can >>> figure it out better, dynamically, but that code's not ready yet. >>> Instead I'm trying to pull together a shaperprobe that detects = modern >>> conditions better, statically, at least. >>>=20 >>> Uplink speed is the principal bottleneck problem that users deal = with. >>>=20 >>> I'm running SFQ on all interfaces. This helps break up streams into >>> more manageable chunks. It can be really NICE, on ethernet. In fact, >>> most of my network bottlenecks have moved to my desktops and laptops >>> in the general case, and to get best results I have to run the = debloat >>> script and enable SFQ everywhere, in this wack-a-mole game. >>>=20 >>> SFQ has positive effects on wireless as sparse streams move forward = in >>> the queue, and are thus shipped as an aggregate at the earliest >>> opportunity. Regrettably there is so much rate-insensitive fixed >>> buffering at present in the Linux wireless stack as to incur huge >>> penalties at variable rates. >>>=20 >>> It can have negative side effects on wireless, as it mucks with = packet >>> aggregation across devices. That said, in home use (rather than with >>> dozens of wireless devices) it should help somewhat. I'm not = worrying >>> about wireless behavior all that much right now, I'm mostly trying = to >>> exercise the new code... as fixing the aggregation problems really >>> needs to have a per-destination queue somehow. >>>=20 >>> Developing correct configuration for RED and ARED is something of a = dark art. >>>=20 >>> The new SFQ prioritizes new streams very well. Perhaps overly well. >>> Eric has a patch in progress >>> to make it have more of an idea of 'how new' a stream is. It = otherwise >>> is very effective in reducing latency for short, sparse, streams. >>>=20 >>> SFQRED's mental model is closer to what an ISP would use on it's >>> downstream link. It is not (quite) right for what a site would use = as >>> an uplink. >>>=20 >>> QFQ, which is what I was using to get 1/d level behavior in the >>> prototype I did several months back, still is hanging under load on >>> cerowrt. It's working on x86. :( Might try working with classful = SFQ >>> stuff instead, or I may give DRR a shot instead. >>>=20 >>> Even getting 1/d is hard because the filters can only use IP and = IPv6 >>> addresses, so a device issuing traffic on both ipv4 and ipv6 can get >>> twice what it deserves in terms of bandwidth, or more if it has >>> multiple ipv6 addresses. >>>=20 >>> My preferred solution to this (and part of the wireless problem) is = to >>> sort things out by source mac address. How to do that, remains a >>> mystery. The way I'm leaning is to invent some sort of "src = mac-to-id" >>> filter that is global router-wide. >>>=20 >>> I tend to view (in the home) as having 1/u network performance as = the >>> ideal. There are exceptions to this, notably video vs. say, >>> bittorrent. A clever way of getting closer to 1/u might be to sense >>> for more recent DNS queries and move that to a more interactive = class. >>>=20 >>> I got 1/d level performance, vs bittorrent, several months back, = using >>> a combination of HTB, and a >>> two tier QFQ, then red model. I was happy with this, but QFQ was >>> required. Perhaps I can make >>> SFQRED do this with the right filters, or switch to a combination of >>> DRR and SFQRED.... >>>=20 >>> Anyway, at the present time, I'm trying a few approaches, the most >>> promising one is a two or three tier model using SFQRED, with a very >>> limited number of things prio 1 (dns), 2 (mostly everything), 3 >>> classified and background traffic and torrent, where classifiable. >>> Classification is a rathole however, and I'd rather be aiming for = 1/d >>> than 1/f. >>>=20 >>> Regardless openwrt's default AQM does lousy queue depth management = at >>> present, and I expect to >>> improve it tremendously over the coming week. >>>=20 >>> -- >>> Dave T=E4ht >>> SKYPE: davetaht >>> US Tel: 1-239-829-5608 >>> FR Tel: 0638645374 >>> http://www.bufferbloat.net >>> _______________________________________________ >>> Bloat mailing list >>> Bloat@lists.bufferbloat.net >>> https://lists.bufferbloat.net/listinfo/bloat >>=20 >=20 >=20 >=20 > --=20 > Dave T=E4ht > SKYPE: davetaht > US Tel: 1-239-829-5608 > FR Tel: 0638645374 > http://www.bufferbloat.net