Hi Fred,
On Dec 17, 2013, at 12:39 , Fred Stratton <fredstrat...@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 <bro...@redhat.com> wrote:
>>
>>> On Sat, 14 Dec 2013 13:24:06 +0100 Sebastian Moeller <moell...@gmx.de>
>>> wrote:
>>>
>>>> On Dec 14, 2013, at 07:26 , Dave Taht <dave.t...@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@lists.bufferbloat.net
>> https://lists.bufferbloat.net/listinfo/cerowrt-devel
>
_______________________________________________
Cerowrt-devel mailing list
Cerowrt-devel@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cerowrt-devel
