[Cerowrt-devel] Linksys wrt1900acs rrul traces ko

[Sebastian Moeller]

Hi John,

On April 8, 2016 3:55:21 PM GMT+02:00, John Yates <john at yates-sheets.org> wrote:
>Sebastian,
>
>Recently you wrote:
>
>In your case select Ethernet with overhead, and manually put 24 into
>these
>> packet overhead field, as the kernel already accounted for 14 of the
>total
>> of 38.
>>
>
>and further down: mi
>
>
>> I assume in your case this will not change your results a lot, as you
>most
>> likely used full MTU packets in the test flows, I believe your low
>latency
>> under load increases show that you have not much buffer bloat left...
>I
>> would still recommend to use the correct per packet overhead to be on
>the
>> right side...
>>
>
>As a layman hoping to use some of this great technology on my forth
>coming
>Omni Turris boxes how am I supposed to derive these num Mkbers?  Is there
>a
>simple series of questions and answers that could figure them out? 

        Well, yes and no. Yes there is an underlaying implicit decision tree that could be turned into a series of questions that allow to deduce the required per packet overhead. And no as far as I know there is no explicit version of this.

In the end it really is not as complicated as it may seem:
0) decide whether you really need an explicit traffic shaper at all.

If no you are done, else

1) research what kind of link you want to shape for, as different link technologies have different overheads. 
So typically you should ask yourself what or where the usual bottleneck link in your internet connection is located, shaping works best for links that are have fixed parameters. Good examples of technologies and links to shape for are e.g. ethernet for an active fiber link (FTTH) or ATM for old ADSL links, or PTM for vdsl2 ( FTTC):
A) Ethernet. This is the signed easiest, just figure out what is used on the wire. Typically that contains the the overhead described in my mail to Richard with the potential addition of up to two VLAN tags (4bytes each).
B) almost ethernet. Some technologies carry Ethernet frames so are similar to ethernet but don't deal in all components of Ethernet, e.g. vdsl2's PTM usesmuch of an Ethernet header but uses no preamble or ifg, but adds a few specific options.
C) ATM. This is both complicated and 'solved' at the same time, see https://github.com/moeller0/ATM_overhead_detector for references. Note this not only affects the per packet overhead but also the link rate to payload rate calculations due to quantized 48/53 encoding.
D) PTM. Similar to ethernet except it introduces a few potential overhead items that are not shared with Ethernet and it also affects payload rate calculations due to 64/65encoding.

So ideally at this point you know what true rate your bottleneck link allows and what overhead is added to each packet. Now the only step left is to figure out how much overhead the kernel already added to each packet's wire-size and reduce the configured per packet overhead by that amount.

The devil, as so often is in the details ;)
'

>Could
>those be turned into some kind of "wizard"?  

        I am pretty sure this could be turned into a series of question's or rather a sequential recipe but it will stay laymen unfriendly (with the potential exception of ATM) as it requires intermediate type technical knowledge about behaviour or links outside the user's direct control. Typically your ISP would know all this, but there does not seem to be a universal way to query an ISP to get the required information.

Otherwise how do you
>expect
>large numbers of users to get their systems properly configured? 

        Honestly, I believe the only real hope for the masses would be a universal adoptation of BQL (byte queue limit) in all CPE and CMTs/DSLAMs... That or doing a bit of research them selves.

>Surely
>you do not want to engage in an email thread with each user who even
>attempts such configuration :-)

        I agree, I believe the gist of a few of such discussions should be turned into an FAQ...

Best Regards
       Sebastian

>
>/john

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