From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ie0-x22a.google.com (mail-ie0-x22a.google.com [IPv6:2607:f8b0:4001:c03::22a]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority" (verified OK)) by huchra.bufferbloat.net (Postfix) with ESMTPS id B05BA21F107 for ; Wed, 29 May 2013 17:34:03 -0700 (PDT) Received: by mail-ie0-f170.google.com with SMTP id e14so8342719iej.1 for ; Wed, 29 May 2013 17:34:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=3Lf+4QMg8BHD01LgkLpWCxhwUaq8Kht9Ne00vgDcp0M=; b=YN60RSrmOJv4eqzdXlaKV3l7oFazgwoem25xLu3urwozYdu4MWYu+q9pxnNVgmkLZU 3nSiM8BMgdk2VtVg/rm+WxZQng2y2TldRG/p33m8xIB+GSQBUdeZb0SfXWxz0hU2cU8Q Aq62wdTcOZ8ENbIPEBUpoVE8ifUAd3qLm8tyWZtKZRY2w/vc0P2hL0ccEA6SIZGfmJJQ L+5TFyHTLNrhrZiZI7Rw4xoaYADB+2/jtQgrC1MA9ZnDayaWG2iEr+qH6xzal3Fw+cAF Am9epz9j+eDxMOzO9wSYjK9pe5JqgDgcIaQiqe7NsPlDvg0M3lrDKDcM0LdaT7I5cNG3 eFYQ== MIME-Version: 1.0 X-Received: by 10.50.120.4 with SMTP id ky4mr2445312igb.86.1369874042802; Wed, 29 May 2013 17:34:02 -0700 (PDT) Received: by 10.64.35.44 with HTTP; Wed, 29 May 2013 17:34:02 -0700 (PDT) Received: by 10.64.35.44 with HTTP; Wed, 29 May 2013 17:34:02 -0700 (PDT) In-Reply-To: <20130529155034.334092c5@nehalam.linuxnetplumber.net> References: <20130529151330.22c5c89e@redhat.com> <1369842724.5109.44.camel@edumazet-glaptop> <20130529155034.334092c5@nehalam.linuxnetplumber.net> Date: Wed, 29 May 2013 17:34:02 -0700 Message-ID: From: Dave Taht To: Stephen Hemminger Content-Type: multipart/alternative; boundary=047d7b8746d4b558ba04dde4a7fe Cc: =?ISO-8859-1?Q?Toke_H=F8iland=2DJ=F8rgensen?= , Mike Frysinger , Jiri Pirko , netdev@vger.kernel.org, Patrick McHardy , Jiri Benc , Steven Barth , bloat , David Miller , Jussi Kivilinna , Felix Fietkau , Michal Soltys Subject: Re: [Bloat] tc linklayer ADSL calc broken after commit 56b765b79 (htb: improved accuracy at high rates) X-BeenThere: bloat@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list List-Id: General list for discussing Bufferbloat List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 May 2013 00:34:03 -0000 --047d7b8746d4b558ba04dde4a7fe Content-Type: text/plain; charset=ISO-8859-1 On May 29, 2013 6:50 PM, "Stephen Hemminger" wrote: > > On Wed, 29 May 2013 08:52:04 -0700 > Eric Dumazet wrote: > > > On Wed, 2013-05-29 at 15:13 +0200, Jesper Dangaard Brouer wrote: > > > I recently discovered that the (traffic control) tc linklayer > > > calculations for ATM/ADSL have been broken by: > > > commit 56b765b79 (htb: improved accuracy at high rates). > > > > > > Thus, people shaping on ADSL links, using e.g.: > > > tc class add ... htb rate X ceil Y linklayer atm overhead 10 > > > > > > Will no-longer get ATM cell tax/overhead adjusted. > > > > > > How can we solve/fix this? > > > Perhaps we can change to use the "stab" system instead (as it does > > > not seem to be broken by the commit). > > > > > > But how do we facilitate a change to use "stab" system (for all the > > > scripts using the old option)? > > > > > > Can we change the iproute2/tc command to handle this transparently, or > > > should we give an error/warning if someone uses "tc" and "linklayer" on > > > a kernel above v.3.8. ? > > > > > > > > > History: > > > - My linklayer ATM changes appeared in kernel 2.6.24 (and iproute2 2.6.25) > > > - The STAB changes appeared in kernel 2.6.27 > > > > > > > Hi Jesper > > > > stab suffers from the same problem : its table driven, so works only for > > packet smaller than a given size. > > > > I am not sure it will solve the ATM logic (with the 5 bytes overhead per > > 48 bytes cell) > > > > btw, even on old kernels : > > > How bad is the failure? If it is fixed, will it break existing installations? > > Which probably means, is anyone but the original developers ever using it > and therefore likely to notice? 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. 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. --047d7b8746d4b558ba04dde4a7fe Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


On May 29, 2013 6:50 PM, "Stephen Hemminger" <stephen@networkplumber.org> wrote:
>
> On Wed, 29 May 2013 08:52:04 -0700
> Eric Dumazet <eric.dumaze= t@gmail.com> wrote:
>
> > On Wed, 2013-05-29 at 15:13 +0200, Jesper Dangaard Brouer wrote:<= br> > > > I recently discovered that the (traffic control) tc linklaye= r
> > > calculations for ATM/ADSL have been broken by:
> > > =A0commit 56b765b79 (htb: improved accuracy at high rates).<= br> > > >
> > > Thus, people shaping on ADSL links, using e.g.:
> > > =A0tc class add ... htb rate X ceil Y linklayer atm overhead= 10
> > >
> > > Will no-longer get ATM cell tax/overhead adjusted.
> > >
> > > How can we solve/fix this?
> > > Perhaps we can change to use the "stab" system ins= tead (as it does
> > > not seem to be broken by the commit).
> > >
> > > But how do we facilitate a change to use "stab" sy= stem (for all the
> > > scripts using the old option)?
> > >
> > > Can we change the iproute2/tc command to handle this transpa= rently, or
> > > should we give an error/warning if someone uses "tc&quo= t; and "linklayer" on
> > > a kernel above v.3.8. ?
> > >
> > >
> > > History:
> > > =A0- My linklayer ATM changes appeared in kernel 2.6.24 (and= iproute2 2.6.25)
> > > =A0- The STAB changes appeared in kernel 2.6.27
> > >
> >
> > Hi Jesper
> >
> > stab suffers from the same problem : its table driven, so works o= nly for
> > packet smaller than a given size.
> >
> > I am not sure it will solve the ATM logic (with the 5 bytes overh= ead per
> > 48 bytes cell)
> >
> > btw, even on old kernels :
>
>
> How bad is the failure? If it is fixed, will it break existing install= ations?
>
> Which probably means, is anyone but the original developers ever using= it
> and therefore likely to notice?

This debugging train stems on part from spending quite some = time being very puzzled about the behavior of DSL against multiple HTB base= d fq codel shapers.

So I'm glad it is a real bug at this layer rather than e= lsewhere. I'll just nip off and write off those datasets now.


--047d7b8746d4b558ba04dde4a7fe--