<p dir="ltr"><br>
On May 29, 2013 6:50 PM, "Stephen Hemminger" <<a href="mailto:stephen@networkplumber.org">stephen@networkplumber.org</a>> wrote:<br>
><br>
> On Wed, 29 May 2013 08:52:04 -0700<br>
> Eric Dumazet <<a href="mailto:eric.dumazet@gmail.com">eric.dumazet@gmail.com</a>> wrote:<br>
><br>
> > On Wed, 2013-05-29 at 15:13 +0200, Jesper Dangaard Brouer wrote:<br>
> > > I recently discovered that the (traffic control) tc linklayer<br>
> > > calculations for ATM/ADSL have been broken by:<br>
> > >  commit 56b765b79 (htb: improved accuracy at high rates).<br>
> > ><br>
> > > Thus, people shaping on ADSL links, using e.g.:<br>
> > >  tc class add ... htb rate X ceil Y linklayer atm overhead 10<br>
> > ><br>
> > > Will no-longer get ATM cell tax/overhead adjusted.<br>
> > ><br>
> > > How can we solve/fix this?<br>
> > > Perhaps we can change to use the "stab" system instead (as it does<br>
> > > not seem to be broken by the commit).<br>
> > ><br>
> > > But how do we facilitate a change to use "stab" system (for all the<br>
> > > scripts using the old option)?<br>
> > ><br>
> > > Can we change the iproute2/tc command to handle this transparently, or<br>
> > > should we give an error/warning if someone uses "tc" and "linklayer" on<br>
> > > a kernel above v.3.8. ?<br>
> > ><br>
> > ><br>
> > > History:<br>
> > >  - My linklayer ATM changes appeared in kernel 2.6.24 (and iproute2 2.6.25)<br>
> > >  - The STAB changes appeared in kernel 2.6.27<br>
> > ><br>
> ><br>
> > Hi Jesper<br>
> ><br>
> > stab suffers from the same problem : its table driven, so works only for<br>
> > packet smaller than a given size.<br>
> ><br>
> > I am not sure it will solve the ATM logic (with the 5 bytes overhead per<br>
> > 48 bytes cell)<br>
> ><br>
> > btw, even on old kernels :<br>
><br>
><br>
> How bad is the failure? If it is fixed, will it break existing installations?<br>
><br>
> Which probably means, is anyone but the original developers ever using it<br>
> and therefore likely to notice?</p>
<p dir="ltr">This debugging train stems on part from spending quite some time being very puzzled about the behavior of DSL against multiple HTB based fq codel shapers. </p>
<p dir="ltr">So I'm glad it is a real bug at this layer rather than elsewhere. I'll just nip off and write off those datasets now.</p>
<p dir="ltr"> <br>
</p>