moeller0 at gmx.de
Sun Apr 12 20:23:13 EDT 2015
on a added note below; Note to self "reading actually helps"
On Apr 13, 2015, at 02:15 , Sebastian Moeller <moeller0 at gmx.de> wrote:
> Hi Jonathan,
> On Apr 13, 2015, at 01:55 , Jonathan Morton <chromatix99 at gmail.com> wrote:
>>> On 13 Apr, 2015, at 02:50, Sebastian Moeller <moeller0 at gmx.de> wrote:
>>> As mentioned above, as long as cake can work with tc’s stab option all framing and overhead handling should be available to whoever needs it.
>> Remind me to look into how to use that, then.
> basically you add:
> stab mtu 2047 tsize 512 mpu 0 overhead 40 linklayer atm
> to the top level qdisc invocation, it fudges the size variable in the SKB? just as the kernels internal accounting for the ethernet header does, and all qdisc will see the fudged value, this is unlike HTB private implementation of basically the same (TB’s version has some advantages with GRO though).
> $TC qdisc add dev $DEV root handle 1: stab mtu 2047 tsize 512 mpu 0 overhead 40 linklayer atm htb default 12
> Note: mtu in the stab context only defines the upper bound for which the size table gets created (this is the limit up to which stab works reliable), tsize gives the number of entries in the table, for ATM all increases are at multiples of 16, so 2048/512 = 4bits is enough, and mpu allows to specify a minimum packet size. All in all stab gives more freedom than strictly needed for atm ,link layer accounting...
>> If there’s a better way than manually calculating ceil(len/48)*53, so much the better.
Ignore my gibberish below, that is almost all required: ceil(len+additional_per_packet_overhead/48)*53 seems the winner ;) Effectively this is what stab should offer, but its implementation with a table has issues if packets are larger than the table estimated…
> Well, “stab” is so much better than statically accounting for the ~9% ATM cell overhead tax that it is just not funny anymore. Due to the AAL5’s? weird idea that each payload package has to fill an integer number of ATM cells, small packets can get an obscene amount of additional overhead: worst case is something like 1 ATM cell with of data + 1 byte, which will drag in another ATM cell with 47 bytes padding… increasing the overhead by 100% on top of the 9% cell tax and the normal per packet overhead gunk ISPs force unto the unlucky ATM users…
> Best Regards
>> - Jonathan Morton
> Cake mailing list
> Cake at lists.bufferbloat.net
More information about the Cake