Not sure if suitable but netem rate have a cell mechanism as well. See man netem
Eric Dumazet <[email protected]> schrieb: >On Wed, 2013-05-29 at 15:50 -0700, Stephen Hemminger wrote: >> On Wed, 29 May 2013 08:52:04 -0700 >> Eric Dumazet <[email protected]> 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 >[email protected] >https://lists.bufferbloat.net/listinfo/bloat > _______________________________________________ Bloat mailing list [email protected] https://lists.bufferbloat.net/listinfo/bloat
