[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <20130529151330.22c5c89e@redhat.com>
Date: Wed, 29 May 2013 15:13:30 +0200
From: Jesper Dangaard Brouer <brouer@...hat.com>
To: Stephen Hemminger <stephen@...workplumber.org>,
Eric Dumazet <eric.dumazet@...il.com>,
David Miller <davem@...hat.com>, j.vimal@...il.com,
Michal Soltys <soltys@....info>,
Mike Frysinger <vapier@...too.org>,
Jussi Kivilinna <jussi.kivilinna@...et.fi>,
Patrick McHardy <kaber@...sh.net>,
Jiri Pirko <jpirko@...hat.com>
Cc: brouer@...hat.com,
Toke Høiland-Jørgensen <toke@...e.dk>,
Dave Taht <dave.taht@...il.com>, netdev@...r.kernel.org,
bloat@...ts.bufferbloat.net, Dan Siemon <dan@...erfire.com>,
Jim Gettys <jg@...edesktop.org>,
Steven Barth <cyrus@...nwrt.org>, Felix Fietkau <nbd@....name>,
Jiri Benc <jbenc@...hat.com>
Subject: tc linklayer ADSL calc broken after commit 56b765b79 (htb: improved
accuracy at high rates)
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
--
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
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists