[Bloat] ADSL, ATM drivers, bloat, education & confusion

[Sebastian Moeller]

Hi Jesper,



On June 11, 2015 1:16:15 PM GMT+02:00, Jesper Dangaard Brouer <jbrouer at redhat.com> wrote:
>
>On Sat, 6 Jun 2015 16:29:15 +0200 Sebastian Moeller <moeller0 at gmx.de>
>wrote:
>
>> On Jun 6, 2015, at 15:38 , Kevin Darbyshire-Bryant
><kevin at darbyshire-bryant.me.uk> wrote:
>> 
>[...]
>> > The problem I have is setting outbound rate limiting.  I was hoping
>> > that 'cake' without the 'bandwidth' parameter would work on the
>> > 'backpressure' from the ATM(?) driver, sadly this wasn't the case
>> > and so setting a bandwidth limit (I'm not in a position to test the
>> > new keywords for ATM encapsulation etc yet) was the only way
>> > forward.  
>> 
>>  This is rather important to get right, ATM’s arcane 48/53
>> encapsulation only leaves 100*48/53 = 90.5% of the sync rate for
>> useable bits, and even those need to contain all the headers specific
>> to your line (plus AAL5’s unfortunate choice of fitting each packet
>> into an integer number of ATM cells), mean that without AQM taking
>> the link layer encapsulation into account you need to aim for roughly
>> 80-85% of the sync rates on and ATM link. With a link that disappears
>> often I currently would recommend sqm-scripts as weapon of choice
>> (you should be able to get cake into sqm-scripts) as the IFB needs to
>> be set up again after the “connected” interface reappears, which
>> current sqm-scripts should do for you...
>
>That is true, the ATM overhead on ADSL is very important to get right
>for your ratelimiting work as intended (that is you gain control over
>the queue).
>

        I want to add that Jesper was essential in teaching the Linux kernel to properly account for all the quirks in the ATM/aal5 Linklater. So we are standing on his shoulders, so to speak ;) to be able to see as far as we do... His original thesis is still findable under http://www.adsl-optimizer.dk/ and certainly worth reading for ATM "sufferers".

>The iproute2 "tc" have supported option "linklayer atm" and "overhead"
>for quite some time now (since 2008).  All the rate_tables based
>schedulers (e.g. HTB, TBF) have these options.
>
>There is also the more generic "stab" that allow linklayer adaptation
>to
>work for any qdisc. See man tc-stab [1]

        Cake has its own independent implementation of per-packet-overhead and atm-celling accounting, in the spirit of making shaper setup easy for mortals. Sqm-scripts allows to select which of the link layer accounting methods to use and calls them htb_private and tc_stab I believe.

Best Regards
        Sebastian


-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.