netdev - Re: [Bloat] tc linklayer ADSL calc broken after commit 56b765b79 (htb: improved accuracy at high rates)

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

Message-ID: <fgl2990m2s4w7vetl590cuie.1369887601987@email.android.com>
Date:	Thu, 30 May 2013 06:20:01 +0200
From:	Hagen Paul Pfeifer <hagen@...u.net>
To:	Eric Dumazet <eric.dumazet@...il.com>
Cc:	Stephen Hemminger <stephen@...workplumber.org>,
	Toke Høiland-Jørgensen <toke@...e.dk>,
	Mike Frysinger <vapier@...too.org>,
	Jiri Benc <jbenc@...hat.com>, Jiri Pirko <jpirko@...hat.com>,
	netdev@...r.kernel.org, bloat@...ts.bufferbloat.net,
	Patrick McHardy <kaber@...sh.net>,
	Steven Barth <cyrus@...nwrt.org>,
	David Miller <davem@...hat.com>,
	Jussi Kivilinna <jussi.kivilinna@...et.fi>,
	Felix Fietkau <nbd@....name>, Michal Soltys <soltys@....info>
Subject: Re: [Bloat] tc linklayer ADSL calc broken after commit 56b765b79
 (htb: improved accuracy at high rates)

Not sure if suitable but netem rate have a cell mechanism as well. See man netem

Eric Dumazet <eric.dumazet@...il.com> schrieb:

>On Wed, 2013-05-29 at 15:50 -0700, Stephen Hemminger wrote:
>> On Wed, 29 May 2013 08:52:04 -0700
>> Eric Dumazet <eric.dumazet@...il.com> 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?
>
>Adding the logic on the kernel is doable, by adding some clean
>attributes so that tc can setup the feature, and report the attributes
>back.
>
>cpus are fast today and can perform the atm cell/overhead faster than a
>table lookup.
>
>
>
>_______________________________________________
>Bloat mailing list
>Bloat@...ts.bufferbloat.net
>https://lists.bufferbloat.net/listinfo/bloat
>