From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) (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 536FF21F1C4 for ; Tue, 17 Dec 2013 00:22:36 -0800 (PST) Received: from u-089-cab203a2.am1.uni-tuebingen.de ([134.2.89.4]) by mail.gmx.com (mrgmx003) with ESMTPSA (Nemesis) id 0MNIAz-1Vqv3218Kf-006xPy for ; Tue, 17 Dec 2013 09:22:33 +0100 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Sebastian Moeller In-Reply-To: <20131217090309.040a7ff3@redhat.com> Date: Tue, 17 Dec 2013 09:22:33 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <004A2366-B04D-4B12-A870-820F38111410@gmx.de> References: <99B7074D-94EF-4EAB-9E00-C87C686A33B4@gmx.de> <20131217090309.040a7ff3@redhat.com> To: Jesper Dangaard Brouer X-Mailer: Apple Mail (2.1510) X-Provags-ID: V03:K0:Hp/C2d7lOd3vOgx1TpYqWFgitFsG1mDiR7N4StU6MbjNSIofyzr xMhKIM2Bag0JcVwbU2hD8ZBJ+qHKgGjNY4ODyvZjw9lumNeK9vGfZI+jOuejcD7j/MVcC48 jy60U7568aqJuyjk+2+zTapZ10TvW1wLZ0QEVmWPqbXcJGFVqbJp4VCFNK+Sa0C/0r4eMQj kk++a42S4sgzc3EmoYkvQ== 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 08:22:36 -0000 Hi Jesper, 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 >>>=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? >>=20 >> 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. >>=20 >> 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 >=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? >>=20 >> 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). >=20 > 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. > 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? >=20 > I have actually not played with stab. Best Regards Sebastian >=20 > --=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