Hi Jonathan,
> On Jun 2, 2016, at 16:49 , Jonathan Morton <[email protected]> wrote:
>
>>> It would be nice if LuCI could infer information about the likely
>>> overheads from the rest of the configuration, and apply (or suggest &
>>> default) the correct keywords in sqm-scripts. That would make the
>>> feature much more widely used.
>>
>> We can probably do this for the most common cases, but am not so sure
>> it's unambiguous when to pick what. If someone can supply a couple of
>> examples of configuration where we are fairly certain we know what to
>> pick, I can look into how that can be inferred in luci…
>
> The most obvious cases are where there is an ADSL or VDSL modem built into
> the router, as there is on my Buffalo WBMR (though I don’t currently have a
> working ADSL line to demonstrate a live example). SQM on the WAN-facing
> interfaces which (directly or indirectly) use that modem should then infer
> the PPP and ATM modes from the modem’s configuration, which I know is visible
> to LuCI in some form.
>
> It’s slightly less obvious what to do with a standalone router, where there
> is a separate modem handling the PPP endpoint, thus the WAN interface appears
> in all respects to be Ethernet. For this case, an easy way of setting the
> “conservative”, “bridged-ptm" or “pppoe-ptm” keywords should do the trick,
> perhaps with “conservative” being the sane default. The PTM keywords are
> better suited to VDSL installations. I suspect cable and cell modems may
> work best *without* overhead compensation.
I do not agree that these are too helpful unless the user already has
lots of knowledge, but then they are hardly an improvement on “overhead N”.
>
> As for the “conservative” keyword, it assumes ATM encapsulation and exactly
> one ATM cell of inner encapsulation overhead, the latter exceeding all known
> combinations of inner encapsulation used in practice (except for bizarre
> cases involving IP-in-IP tunnelling). It’s intended to be a reasonable
> default where it is known or suspected that encapsulation is in use, but no
> specifics are known.
So far I have not encountered overhead >= 48, that is true. But I have
also never seen a blue whale, which I do not want to be interpreted as me
doubting their existence. In reality 48 bytes still seems like a likely upper
bound for per-packet overhead on an ATM link, so of all the keywords,
conservative might survive, if renamed “conservative_adsl” or
“conservative_atm”. “pppoe-ptm” however is a good example for an under-defined
keyword… what exactly is this supposed to entail?
>
> Sebastian seems to have more detailed information about what encapsulation
> combinations are actually in use in Germany, and can doubtless advise on how
> these show up in LuCI on an ADSL router.
Not at all, some details of the encapsulation are not easily
extractable from the typical modem’s dsl-information tab. My attempts at
measuring the per-packet-overhead culminated in what I documented under
https://github.com/moeller0/ATM_overhead_detector and
https://github.com/moeller0/ATM_overhead_detector/wiki I stopped believing this
is “simple” a long time ago; I also failed to come up with a method to measure
the actual overhead on VDSL links…
Best Regards
Sebastian
>
> - Jonathan Morton
>
> _______________________________________________
> Cake mailing list
> [email protected]
> https://lists.bufferbloat.net/listinfo/cake
_______________________________________________
Cake mailing list
[email protected]
https://lists.bufferbloat.net/listinfo/cake
