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?
On 17/12/13 08:22, Sebastian Moeller wrote:
Hi Jesper,
On Dec 17, 2013, at 09:03 , Jesper Dangaard Brouer <[email protected]> wrote:
On Sat, 14 Dec 2013 13:24:06 +0100 Sebastian Moeller <[email protected]> wrote:
On Dec 14, 2013, at 07:26 , Dave Taht <[email protected]> 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
[email protected]
https://lists.bufferbloat.net/listinfo/cerowrt-devel
_______________________________________________
Cerowrt-devel mailing list
[email protected]
https://lists.bufferbloat.net/listinfo/cerowrt-devel
