[Cerowrt-devel] aqm gui feedback on cerowrt-3.10.24-1 for linklayer adaption

[Sebastian Moeller]

Hi Fred,


On Dec 17, 2013, at 12:39 , Fred Stratton <fredstratton at imap.cc> wrote:

> In the new interface, htb_private is not an explicit option.
> 
> 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…
	BUt if you need htb_private, all you need to foo is to uncomment one line in aqm.lua.

best
	Sebastian

> 
> 
> On 17/12/13 08:22, Sebastian Moeller wrote:
>> Hi Jesper,
>> 
>> 
>> On Dec 17, 2013, at 09:03 , Jesper Dangaard Brouer <brouer at redhat.com> wrote:
>> 
>>> On Sat, 14 Dec 2013 13:24:06 +0100 Sebastian Moeller <moeller0 at gmx.de> wrote:
>>> 
>>>> On Dec 14, 2013, at 07:26 , Dave Taht <dave.taht at gmail.com> 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 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.
>> 
>>> 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!
>> 
>>> 
>>>>> 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.
>> 
>>>  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
>> 	Sebastian
>>> -- 
>>> 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 at lists.bufferbloat.net
>> https://lists.bufferbloat.net/listinfo/cerowrt-devel
>