i have a vdsl2 link ptm connection with vlan, no pppoe, from wiki i should use ethernet with overhead of 26. was wondering if there is any difference for sqm between using link layer adaptation tab in luci or using manual parameters in ingress/egress.
No, in the latter version you still have the ptm keyword that is not in the former, and both are missing a mpu 68 stanza. The ptm keyword aims at taking care of PTM's 64/65 encoding, but it does so on a packet by packet fashion that requires to do individual calculations per packet. Instead I would propose to simply set the shaper 100-100*64/65 = 1.6 percentage points lower than otherwise intended and thereby statically solving the PTM encoding issue (unlike ATM 48/53 encapsulation, which is per packet and introduces packet size dependent padding, ptm encapsulation is not on a per packet basis and can be addresses by statically reducing the shaper bandwidth).
so use 26 overhead link layer ethernet in config (or from luci) and just play around with bandwidth until i get good result from dslreports or flent, no need to use ptm keyword, i'm getting this right (sorry bit of a noob here)?
Also note that this enables ECN for ingress and egress and configures for by-internal-IP-fairness, if you do not want that remove the dual-srchost and dual-dsthost keywords. Also this uses the nat keyword as that is required by the dual-xxhost isolation modes.
i'll play around with this but those number are doing the magic for now
have both to 1 becouse i don't really trust what my provider is doing with marking, or should i?
was totally unaware of this options, will test and get documented (the mpu should refer to your hint about ptm in previous post)
i'm aware how ip fairness works, i will test your suggestion for ecn (i had it on just for ingress btw), will also do some reading on this. apart from this few points i almost got my config right, cannot thank you enough for such a detailed explenation and for tacking time to write a full config. i will mark this as solved since the original question was clearly answered. if you have any other suggestion i will gladly read it
No, that is a policy decision you need to take, squashing is the safer option, good catch.
Yes, and cake will happily ignore tcMTU and tcTSIZE, just as it should, as these are specific to tc-stab, and cake has its own, arguably better way to deal with per packet overhead.
Yes, this is the default in sqm, but with your upload you might as well enable it, the idea behind the default is that in a slow link, not sending a packet allows us to send more important packets earlier.
took me ages to get a decent connection and the all is ruined by a crappy provider modem! anyways just for reference this is my config with your suggestions (testing with no nat at the moment):
