From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ww0-f47.google.com (mail-ww0-f47.google.com [74.125.82.47]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority" (verified OK)) by huchra.bufferbloat.net (Postfix) with ESMTPS id 98F8D200833 for ; Thu, 23 Feb 2012 11:10:17 -0800 (PST) Received: by wgbds11 with SMTP id ds11so1184427wgb.28 for ; Thu, 23 Feb 2012 11:10:15 -0800 (PST) Received-SPF: pass (google.com: domain of dave.taht@gmail.com designates 10.180.7.231 as permitted sender) client-ip=10.180.7.231; Authentication-Results: mr.google.com; spf=pass (google.com: domain of dave.taht@gmail.com designates 10.180.7.231 as permitted sender) smtp.mail=dave.taht@gmail.com; dkim=pass header.i=dave.taht@gmail.com Received: from mr.google.com ([10.180.7.231]) by 10.180.7.231 with SMTP id m7mr7217027wia.3.1330024215748 (num_hops = 1); Thu, 23 Feb 2012 11:10:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=+TMQ6syqOgK7TB+TLXjxnv8/jYgO/FiOrSORMg6xpyg=; b=KLQ8nt1NvP4ctDxK/N1oLY1HYgSvK/aXCkDviKNcR0sbItlIYlXhA3kOf5/fUu0rrx Px2sbcYCeSblAbvNJwCRyEghFr2EdrMfh7jMxX6h+qFqGFei8apjU27Vqovig92r7Gpf YKP8bIL5C9PdnCUagyi+Phw2cImBfLtyc8w5c= MIME-Version: 1.0 Received: by 10.180.7.231 with SMTP id m7mr5883037wia.3.1330024215621; Thu, 23 Feb 2012 11:10:15 -0800 (PST) Received: by 10.223.117.1 with HTTP; Thu, 23 Feb 2012 11:10:15 -0800 (PST) In-Reply-To: References: Date: Thu, 23 Feb 2012 19:10:15 +0000 Message-ID: From: Dave Taht To: Sebastian Moeller Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: cerowrt-devel@lists.bufferbloat.net Subject: Re: [Cerowrt-devel] smoketest BQL-40 is out 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: Thu, 23 Feb 2012 19:10:18 -0000 On Thu, Feb 23, 2012 at 6:38 PM, Sebastian Moeller wrote: > Hi Dave, > > thanks for your reply. > > > On Feb 23, 2012, at 2:49 AM, Dave Taht wrote: > >> I'm aware there are several messages in >> the backlog I need to respond to, but I am travelling >> at the moment and eyeball deep in meetings. (presently in NJ, >> next week philly, and then I get back to the bloatlab in isc >> in california friday-ish. >> >> As best as I recall there was no real difference between >> the AQM script and the QoS script in bql-40, and I may >> not get around to doing a 'bql-42' per se' but go right >> into the 3.3 development process. > > =A0 =A0 =A0 =A0Well in my case AQM does not work at all (if I shape to 1/= 5 of my uplink line rate I still see transfers running at 1/1 uplink rate, = so clearly somehow on my system AQM does not work) I will have a try at fig= uring out why AQM does not seem to activate... I was not running it via the web interface. Splitting off 'AQM' from 'QOS' is a start at to be able to a/b the two different systems easily and then fold back the good bits upstream on the qos side, and continue to revise the aqm side. It wouldn't surprise me if the web side was entirely borked, and I won't be in a position to work on this until late next week, unless I get some spare time this weekend. /etc/init.d/aqm enable - to run at boot edit /etc/config/aqm - and make the enable line have '1' /etc/init.d/aqm start >> >> This will not be the final url for the 3.3 development >> series, but >> >> http://huchra.bufferbloat.net/~cero1/3.3/ >> >> has that. >> >> I made a small dent in the qos/aqm problem there, >> (my intent was to basically treat the above as 'bql-41' - >> I wanted to treat 3.3 issues and bql issues separately, >> but lack time to do both, and 3.3 is going swimmingly, so...) >> >> but I'm puzzled as to what you are seeing below. >> >> 0) Did you enable the aqm script? If you merely run it >> without enabling it, nothing happens. Similarly, the qos script >> needs to be disabled. > > =A0 =A0 =A0 =A0Sorry for not being clear, I always had only the module un= der test enabled, the other one was always disabled. One thing I noticed, w= hen enabling QoS I get the "Applying changes" info widget and it will state= "/etc/config/qos" while enabling AQM will not show any "/etc/config" info,= but that might be purely cosmetic. Will investigate, as it looks somehow A= QM is never really enabled. > =A0 =A0 =A0 =A0Question do I need to install any package under the system= ->software tab for AQM to fully work? I assume not. No, aside from the web interface being as yet untested... > >> >> 1) Neither the AQM nor qos script does ADSL overhead right, >> and I'd got puzzled on what was 'right' after fiddling with it. > > =A0 =A0 =A0 =A0Well, I agree that the overhead calculation as implemented= in generate.sh is quite dubious (it looks like a stochastic approach). Completely dubious and probably dates back to before the stab work. >So I used the fact that cewrowrt comes with quite recent tc and used tc's = "stab" option as that seems theoretically solve both the ATM carrier packet= quantization as well as the per packet overhead issues quite well. Yes. > >> >> 2) both qos and aqm calculated the sfq 'limit' variable wrong, and >> neither did ipv6 work right at all. > > =A0 =A0 =A0 =A0I still have no IPv6 available so I did not test that. And= even with the limit error QoS still works okay. (And I quite sure so will = AQM once I manage to actually activate it :) ) Well, my concern is mostly that bittorrent will misbehave worse under this system than otherwise. Qos-scripts uses hfsc + sfq for two bins, and hfsc + red for two other bins. Both sfq and red have improvements that qos-scripts should now be automatically picking up - red was entirely broken before kernel 3.2, actually. AQM-scripts - at least this cut at it - will use hfsc + sfqred for all bins, and saner limits for both sfq and the red component of sfqred which will hopefully I have to admit that the simplest possible implementation of the new stuff in debloat is performing pretty well - which is merely htb + 1 bin of sfqred. So if you pull down the latest debloat from the deBloat repo, and just run a command line of IFACE=3Dge00 QMODEL=3Dhtb_sfq_red UPLINK=3Dwhatever_in_kbits /usr/sbin/debl= oat the results should be pretty good. I'm thinking a two tier model (Best effort and background) will be pretty good, 3 tiers and I can emulate most of pfifo_fast's behavior, but I don't see a need for the 4 tier model in qos-scripts, but that's why we test... > >> >> I believe, but don't remember, that at least those fixes got made in >> the 3.3rc4-1 code. Actually there's a better fix for the ipv6 issue >> than what's there=85 > > =A0 =A0 =A0 =A0Ah, so I will keep changing my firmware :) Like I said, it's mostly just scripts now.... no huge need for that. >> >> 3) I am not intending to stick with the aqm script as structured now, >> but to finish modifying the 'debloat' script to have all the features re= quired. >> >> that one has a bunch of semi-working queue models in it. >> >> If yer gonna hack scripts, please take a look at that one. >> There are plenty of things it needs and the qos and aqm scripts >> are more feature complete, tho=85 > > =A0 =A0 =A0 =A0OH, thanks for the pointer, I have not looked at debloat r= ecently, but I am somewhat confused by the generate.sh and trulls.awk combi= nation, so I hope that debloat is more accessible for non-programmers... There is some really good stuff in the current combo, but I too found the amalagation of shell and awk kind of difficult. Wanted one language, with floating point, which was why I ended up going for lua, which has it's own problems too, but... > > >> >> 4) re updates: I have to warn against doing sysupgrade "and keep files >> in place", as the based filesystem does change, and I'm not making >> huge attempts at dealing with that. so doing a backup >> then a sysupdate -n (-n meaning don't preserve files over the backup) >> is generally a good idea. > > =A0 =A0 =A0 =A0Thanks for the advise, I actually reflashed the factory fi= rmware for bql-40 and called it update, sorry for being unclear. Actually t= he installation flashing instructions (http://www.bufferbloat.net/projects/= cerowrt/wiki/CeroWrt_flashing_instructions) were quite specific about which= method one should use. Yep. Large red letters and everything. > > >> >> anyway: >> >> commit be09b8c15b6dc6bf4cb7da3112c598138a9c77ef >> Author: Dave Taht >> Date: =A0 Tue Feb 14 14:38:40 2012 +0000 >> >> =A0 =A0SFQ is limited in packets. RED is in bytes. tcrules.awk conflated= these >> >> =A0 =A0The original openwrt shaper took the RED byte calculation... >> =A0 =A0and reused it to specify a limit for sfq. However, sfq uses >> =A0 =A0packets rather than bytes, so it was specifying, say 16000 bytes >> =A0 =A0and translating that to 16000 packets. >> >> =A0 =A0This was not an error I prior to 3.3, because SFQ had a >> =A0 =A0hard coded limit of 127 packets. It is now. >> >> =A0 =A0So this commit puts a lower and upper bound on the maximum packet= s >> =A0 =A0that is sane, but is not pre 3.2 compatible. >> >> commit 44f8febbd34686564516c3261a911bd7cffcf714 > > =A0 =A0 =A0 =A0Thanks a lot for the great project. Getting there! > Best > =A0 =A0 =A0 =A0Sebastian > > >> >> >> On Thu, Feb 23, 2012 at 6:21 AM, Sebastian Moeller wro= te: >>> Hi Dave, >>> >>> I finally got around to update from rc6 to bql-40, to try the ATM shapi= ng. The update was a breeze, great work! >>> =A0 =A0 =A0 =A0I am sad to report that for my ATM link AQM does not wor= k for me as well as QoS does. My measurement consists out of using ping to = get the RTT to the first ISP hop (as taken from trace route) while concurre= ntly saturating the up link with a dropbox upload (which I usually give tha= t a headstart of 10 seconds to go into bandwidth ceiling): AQM gives the sa= me bad avg RTT of 1.2 seconds as no shaping at all does, while QoS gives me= an avg RTT of around 24ms (best case RTT is around 13ms on my link, so the= link stays pretty useable). >>> =A0 =A0 =A0 =A0I tried to apply the same changes to /usr/lib/aqm/genera= te.sh and /usr/lib/qos/generate.sh to make the them better understand the p= eculiarities of my ATM adsl1 connection, but it seems I did something wrong= for the AQM script since my change does not have any effect there=85 (both= modified files attached). I usually only =A0shape up- and down-stream to 9= 7% of the line rate, which works ok with QoS. (And all my tests have been d= one, very unscientifically, using my mac laptop over the 5GHz wireless band= of the router=85 ) >>> >>> >>> >>> >>> =A0 =A0 =A0 =A0While this is not too helpful, it might give some hints = for bql-42, as from the roadmap I take it you will tackle the dsl issue the= re. I am just about to move and switch from DSL to cable internet, so unfor= tunately this might be my last test=85 >>> >>> (BTW, I have been playing with the -s option of ping to change the payl= oad size and for my measly 3008kbps down, 512kbps up connection I can actua= lly see the 48 byte ATM package boundaries in avg RTTs (-c 100), for each n= ew ATM package I roughly get 1ms added to the RTT (as expected when doing t= he math the my line rate). So I think it should be possible to figure out w= hether a link uses ATM as carrier or not (IIRC newer ADSL systems like AT&T= 's verse HSI use ADSL2 over PTM-TC instead of ATM so touch connections stil= l have per package overhead to account for but lack the weird ATM repack is= sues). >>> =A0 =A0 =A0 =A0I also have a hunch that using this method it should be = possible to deduct a link's overhead (as taken understood by tc's step opti= on) from a properly prepared ping sweep. In other words my hypothesis is th= at it should be possible to run a script on a non-shaped idle link and figu= re out the optimal parameters for stab. But I digress=85 (And alas, in two = days my DSL connection will be gone and I can not even test my hypothesis i= n any meaningful way until then...)) >>> >>> >>> best >>> =A0 =A0 =A0 =A0Sebastian >>> >>> >>> >>> >>> >>> On Feb 14, 2012, at 11:53 AM, Dave Taht wrote: >>> >>>> http://huchra.bufferbloat.net/~cero1/bql-smoketests/bql-40/ >>>> >>>> changes in this release: >>>> >>>> kernel 3.3-rc3 >>>> bind 9.9rc2 >>>> ntpd + dnssec removed (too buggy) >>>> snmpd installed by default >>>> fprobe installed by default >>>> avahi installed by default >>>> >>>> sort of better working 'aqm' shaper installed >>>> ** when configured uses hfsc + sfqred >>>> ** still has trouble with ipv6, diffserv, and tcp elephants >>>> ** no adsl overhead support >>>> >>>> I will be travelling later this week. What I'm mostly >>>> working on right now is better ipv6 support. >>>> >>>> -- >>>> Dave T=E4ht >>>> SKYPE: davetaht >>>> US Tel: 1-239-829-5608 >>>> FR Tel: 0638645374 >>>> http://www.bufferbloat.net >>>> _______________________________________________ >>>> Cerowrt-devel mailing list >>>> Cerowrt-devel@lists.bufferbloat.net >>>> https://lists.bufferbloat.net/listinfo/cerowrt-devel >>> >>> >> >> >> >> -- >> Dave T=E4ht >> SKYPE: davetaht >> US Tel: 1-239-829-5608 >> http://www.bufferbloat.net > --=20 Dave T=E4ht SKYPE: davetaht US Tel: 1-239-829-5608 http://www.bufferbloat.net