Hi Kevin, hi Mark,
Kevin is 100% right!
I guess "linklayer cake" would be better than none...
> On Dec 17, 2017, at 20:23, Kevin Darbyshire-Bryant <kevin@darbyshire-bryant.me.uk> wrote:
>
>
>
>> On 17 Dec 2017, at 15:23, Sebastian Moeller <moeller0@gmx.de> wrote:
>>
>> Hi Mark,
>>
>>> On Dec 17, 2017, at 11:45, Mark Captur <mark.captur@gmail.com> wrote:
>>>
>>> My setup is as follows
>>>
>>> vdsl2 modem doing pppoe itself and nat to 10.x.x.x -> lede master eth0.2 (wan static ip in modem's DMZ) eth0.1 (lan) doing nat to 192.168.1.x
>>>
>>> Here is my current SQM config
>>> config queue 'eth1'
>>> option debug_logging '0'
>>> option verbosity '5'
>>> option qdisc 'cake'
>>> option qdisc_advanced '1'
>>> option ingress_ecn 'ECN'
>>> option egress_ecn 'NOECN'
>>> option qdisc_really_really_advanced '1'
>>> option script 'layer_cake.qos'
>>> option interface 'eth0.2'
>>> option enabled '1'
>>> option eqdisc_opts 'nat rtt 50000 bridged-ptm dual-srchost diffserv4'
>>> option upload '2400'
>>> option linklayer 'ethernet'
>>> option overhead '8'
>>> option squash_dscp '1'
>>> option squash_ingress '1'
>>> option iqdisc_opts 'nat rtt 50000 bridged-ptm dual-dsthost'
>>> option download '0'
>>>
>>> config queue
>>> option debug_logging '0'
>>> option verbosity '5'
>>> option download '0'
>>> option qdisc 'cake'
>>> option script 'layer_cake.qos'
>>> option qdisc_advanced '1'
>>> option squash_dscp '0'
>>> option squash_ingress '0'
>>> option ingress_ecn 'ECN'
>>> option qdisc_really_really_advanced '1'
>>> option egress_ecn 'ECN'
>>> option interface 'eth0.1'
>>> option enabled '1'
>>> option eqdisc_opts 'nat rtt 50000 bridged-ptm dual-dsthost diffserv4'
>>> option upload '30000'
>>> option linklayer 'ethernet'
>>> option overhead '8'
>>>
>>> Is the overhead correct? should i use the bridged-ptm keyword (or should i use pppoe-ptm).
>
>
> Beware of using option linklayer ‘ethernet’ without option linklayer_advanced ‘1’ & option linklayer_adaptation_mechanism ‘default’. Or use linklayer ‘none’.
> Failure to do so will make sqm-scripts use STAB for the link accounting (in essence it lies to cake about the size of packets being passed through it). Better to use cake’s built-in compensation - fewer modules, less code.
I agree, even though for ptm this is less dire than for ATM; still use linklayer default or linklayer cake.
>
> I was bitten by this myself very recently, lost 4 hours of my life & many recompiles before I realised an innocent looking setting (linklayer_advanced) was messing with the packet size (seen by looking at max_len from tc)
I am beginning to wonder whether the attempt to hide complexity behind linklayer_advanced is not simply misguided and should be jettisoned...
>
>>
>> The overhead certainly seems confusing. Personally, I dislike the overhead related compound keywords like *-ptm and would recommend the following:
>> 1) remove the bridged-ptm from the eqdisc/iqdisc fields
>> 2) add "mpu 64" to the eqdisc/iqdisc fields
>> 3) set overhad to 8+18+4 = 30 bytes (you will need to account for everything added on the bottleneck, so your packets will be MTU 1492, to leave room for the PPPoE header that the modem adds).
> MTU 1492 ain’t necessarily so - some vdsl modems in bridge mode support RFC 4638 with baby jumbo frames, thus supporting the normal ethernet MTU of 1500 (and obviating the need to TCP MSS clamping) - ie. if you can do it, you should ;-). You still need to account for the 8 byte PPPOE overhead of course.
And again, Kevin is correct; my rationale might have been faulty but the recommendation still was correct though ;)...
>> 4) DO not set the ptm keyword at all, instead make sure to set the shaper bandwidth to <= sync bandwidth * 64/65 = sync bandwidth * 0.984615384615 (to account for ptm's 64/65 encoding _without_ incurring needless operations per packet).
>>
>> 4) tell us about your ISP and plan ;)
>>
> Cheers,
>
> Kevin D-B
Thanks for your input, as always very much appreciated!
Best Regards
Sebastian
>
> GPG fingerprint: 012C ACB2 28C6 C53E 9775 9123 B3A2 389B 9DE2 334A