From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) (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 37B8821F1F1 for ; Tue, 17 Dec 2013 03:41:49 -0800 (PST) Received: from u-081-c171.eap.uni-tuebingen.de ([134.2.81.171]) by mail.gmx.com (mrgmx001) with ESMTPSA (Nemesis) id 0LdpcB-1VBoyH1ZXX-00j1UO for ; Tue, 17 Dec 2013 12:41:46 +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: <52B037DD.6060406@imap.cc> Date: Tue, 17 Dec 2013 12:41:46 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <99B7074D-94EF-4EAB-9E00-C87C686A33B4@gmx.de> <20131217090309.040a7ff3@redhat.com> <004A2366-B04D-4B12-A870-820F38111410@gmx.de> <52B037DD.6060406@imap.cc> To: Fred Stratton X-Mailer: Apple Mail (2.1510) X-Provags-ID: V03:K0:lqCexx2gzpClyTxB3QCB7eqxl6+endRaPrSnrjcK1BT4BAgcagc WGmVIGeQBOBgrtsxxCP9mNtd9LPQQB5zrDLi6s2rG1zPdSygegKhc6SLC16VST1SOw1bFdR e7zIT8pfNzaIC4MD4b9BBD5cHqVI6007JFL/jdDU1IIYvqUCQa2vC/Svbm8Hu2u5jFu4ub6 8kY2RsNfjVHcaLfOSeoqQ== Cc: cerowrt-devel@lists.bufferbloat.net Subject: Re: [Cerowrt-devel] aqm gui feedback on cerowrt-3.10.24-1 for linklayer adaption 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, 17 Dec 2013 11:41:49 -0000 Hi Fred, On Dec 17, 2013, at 12:39 , Fred Stratton wrote: > In the new interface, htb_private is not an explicit option. >=20 > IF aqm is enabled, and linklayer protocol is 'none', is htb_private = implicitly chosen? No, currently, you have no access to htb_private. I am still = thinking about how to expose this option or if at all. The best way = forward would be to teach the kernel's stab implementation the two = tricks htb_private knows better and then forget about htb_private at = all=85 BUt if you need htb_private, all you need to foo is to uncomment = one line in aqm.lua. best Sebastian >=20 >=20 > On 17/12/13 08:22, Sebastian Moeller wrote: >> Hi Jesper, >>=20 >>=20 >> On Dec 17, 2013, at 09:03 , Jesper Dangaard Brouer = wrote: >>=20 >>> On Sat, 14 Dec 2013 13:24:06 +0100 Sebastian Moeller = wrote: >>>=20 >>>> On Dec 14, 2013, at 07:26 , Dave Taht wrote: >>>>=20 >>>>> 2) it's not clear to me we have to support both the stab and >>>>> htb_private methods of fixing htb's linklayer. It was important = that >>>>> these be fixed for everyone else that uses htb, >>>>> but is one of these is faster than the other? >>>> So, tc_stab is generic in that it should work with HFSC, HTB >>>> and TBF, while htb_private will only work with HTB (it seems TBF = also >>>> has a private method but I have no clue whether that actually = works, I >>>> just noticed that someone from huawei is posting changes to TBF on >>>> linux net-dev). My take is that we should just stick to stab so we = can >>>> keep the same configuration fiels for most scripts people might = come up >>>> with (thing free.qos without HTB). I have no idea which is faster >>>> though. >>>>=20 >>>>> I seem to recall one was >>>>> a calculated value in the kernel, the other some sort of table. >>>> If I recall correctly HTB lost its internal tables to allow >>>> higher rates and/or precision; Jesper than fixed the htb_private = method >>>> to account for the link layer on the fly. So currently HTB is more >>>> advanced than tc_stab, since HTB will allow arbitrarily large = packets >>>> and still do the right thing, while tc_stab will either need = humungous >>>> tables or will not work with jumbo packets and GRO. I think for = shaping >>>> on a home router we could not care less. People who can afford such >>>> large packets and GRO on the router probably have bandwidths = available >>>> that cerowrt does not handle well anyway (picture me heavily = handwaving >>>> here). >>>>=20 >>> Yes, with my recent fix, the HTB linklayer should be more precise = than >>> stab (as HTB linklayer is no longer table based). >> But for DSL stab is precise unless MTU is larger than table size = + overhead. stab modifies the apparent size of packets and that has no = precision issue :) But I think stab should do the same you did with HTB, = namely calculate the link layer adjustment on the fly. >>=20 >>> BUT as stab is more generic, e.g. works on all schedulers, we should >>> move towards that. We should fix stab, in the kernel, to account = for >>> stuff like GSO, and if needed we could easily do "on-the-fly" ATM = cell >>> alignment (like the HTB linklayer patch). >> I agree, the account for GSO is i single line change, so should = be easy, then the fly calculation is a tiny bit more involved. But in = difference to HTB for stab the kernel knows the requested link layer so = no heuristic is needed! >>=20 >>>=20 >>>>> Does >>>>> this choice need to be made by the >>>>> user? >>>> Well, no the user should not care. We should make that >>>> decision for the user; then again unless we are able to constantly >>>> check both methods against each other one will bitrott, so maybe we >>>> should default to tc_stab and make htb_private an advanced >>>> configuration option? Also we should try to drape tc_stab into the >>>> future and teach it the same trick htb_private does (and then also = fix >>>> the fact that tc_stab ignores the information we have about = overhead). >>> What! - Does stab ignore the overhead?!? >> Oh, sorry for being imprecise here. Stab does take the overhead = into account you put in the stab invocation just like HTB. It does not = currently use the kernels information about GSO, so if handed a GSO = packet it will not account for any ethernet header. For the non offload = situation not a big deal, you just include the 14? bytes ethernet header = in overhead, but hopelessly wrong in the GSO situation. Currently = cerowrt does not use GSO so that is theoretical for now. >>=20 >>> The overhead for small (e.g. >>> ACK) packet is *very* important in the ATM/ADSL case, as the small >>> encap overhead cause the packet to use two ATM frames, which is >>> important to account for, because this represent a very big = percentage >>> overhead (62%). Over-more ADSL is especially prone to have many ACK >>> packets travel their upload link (due to the larger download link >>> capacity). >>>=20 >>>=20 >>>> If no one beats me to it I will try to prepare my first patch to = the >>>> kernel to fix this sometime next year; but I reallr really have no = time >>>> for that in the near future, as I have to papers to write and = grants to >>>> write as well as apply for a new position. (Also I am not too keen = of >>>> getting a patch into the kernel, I just want this issue fixed; but >>>> since it looks this itches me most...) >>>>=20 >>>>> The two variants benchmarked? Jesper? >>> I have actually not played with stab. >>=20 >> Best Regards >> Sebastian >>> --=20 >>> Best regards, >>> Jesper Dangaard Brouer >>> MSc.CS, Sr. Network Kernel Developer at Red Hat >>> Author of http://www.iptv-analyzer.org >>> LinkedIn: http://www.linkedin.com/in/brouer >> _______________________________________________ >> Cerowrt-devel mailing list >> Cerowrt-devel@lists.bufferbloat.net >> https://lists.bufferbloat.net/listinfo/cerowrt-devel >=20