From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by huchra.bufferbloat.net (Postfix) with ESMTP id 5CD9B21F1CE for ; Tue, 17 Dec 2013 00:03:19 -0800 (PST) Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id rBH83DHr004629 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 17 Dec 2013 03:03:13 -0500 Received: from localhost (ovpn-116-35.ams2.redhat.com [10.36.116.35]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id rBH83BR3006539; Tue, 17 Dec 2013 03:03:12 -0500 Date: Tue, 17 Dec 2013 09:03:09 +0100 From: Jesper Dangaard Brouer To: Sebastian Moeller Message-ID: <20131217090309.040a7ff3@redhat.com> In-Reply-To: <99B7074D-94EF-4EAB-9E00-C87C686A33B4@gmx.de> References: <99B7074D-94EF-4EAB-9E00-C87C686A33B4@gmx.de> Organization: Red Hat Inc. Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.23 Cc: "cerowrt-devel@lists.bufferbloat.net" , Jesper Dangaard Brouer 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:03:19 -0000 On Sat, 14 Dec 2013 13:24:06 +0100 Sebastian Moeller wrote: > On Dec 14, 2013, at 07:26 , Dave Taht wrote: > > > > > 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. > > > 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). > Yes, with my recent fix, the HTB linklayer should be more precise than stab (as HTB linklayer is no longer table based). 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). > > 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?!? 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). > 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...) > > > The two variants benchmarked? Jesper? I have actually not played with stab. -- 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