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

[Jesper Dangaard Brouer]

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 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