<div dir="ltr">Thank to both of you!<br><div class="gmail_extra"><br><div class="gmail_quote">On 17 December 2017 at 23:35, Sebastian Moeller <span dir="ltr"><<a href="mailto:moeller0@gmx.de" target="_blank">moeller0@gmx.de</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi Kevin, hi Mark,<br>
<br>
Kevin is 100% right!<br>
<div><div class="gmail-h5"><br>
> On Dec 17, 2017, at 20:23, Kevin Darbyshire-Bryant <<a href="mailto:kevin@darbyshire-bryant.me.uk">kevin@darbyshire-bryant.me.uk</a><wbr>> wrote:<br>
><br>
><br>
><br>
>> On 17 Dec 2017, at 15:23, Sebastian Moeller <<a href="mailto:moeller0@gmx.de">moeller0@gmx.de</a>> wrote:<br>
>><br>
>> Hi Mark,<br>
>><br>
>>> On Dec 17, 2017, at 11:45, Mark Captur <<a href="mailto:mark.captur@gmail.com">mark.captur@gmail.com</a>> wrote:<br>
>>><br>
>>> My setup is as follows<br>
>>><br>
>>> 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<br>
>>><br>
>>> Here is my current SQM config<br>
>>> config queue 'eth1'<br>
>>>Â Â Â Â option debug_logging '0'<br>
>>>Â Â Â Â option verbosity '5'<br>
>>>Â Â Â Â option qdisc 'cake'<br>
>>>Â Â Â Â option qdisc_advanced '1'<br>
>>>Â Â Â Â option ingress_ecn 'ECN'<br>
>>>Â Â Â Â option egress_ecn 'NOECN'<br>
>>>Â Â Â Â option qdisc_really_really_advanced '1'<br>
>>>Â Â Â Â option script 'layer_cake.qos'<br>
>>>Â Â Â Â option interface 'eth0.2'<br>
>>>Â Â Â Â option enabled '1'<br>
>>>Â Â Â Â option eqdisc_opts 'nat rtt 50000 bridged-ptm dual-srchost diffserv4'<br>
>>>Â Â Â Â option upload '2400'<br>
>>>Â Â Â Â option linklayer 'ethernet'<br>
>>>Â Â Â Â option overhead '8'<br>
>>>Â Â Â Â option squash_dscp '1'<br>
>>>Â Â Â Â option squash_ingress '1'<br>
>>>Â Â Â Â option iqdisc_opts 'nat rtt 50000 bridged-ptm dual-dsthost'<br>
>>>Â Â Â Â option download '0'<br>
>>><br>
>>> config queue<br>
>>>Â Â Â Â option debug_logging '0'<br>
>>>Â Â Â Â option verbosity '5'<br>
>>>Â Â Â Â option download '0'<br>
>>>Â Â Â Â option qdisc 'cake'<br>
>>>Â Â Â Â option script 'layer_cake.qos'<br>
>>>Â Â Â Â option qdisc_advanced '1'<br>
>>>Â Â Â Â option squash_dscp '0'<br>
>>>Â Â Â Â option squash_ingress '0'<br>
>>>Â Â Â Â option ingress_ecn 'ECN'<br>
>>>Â Â Â Â option qdisc_really_really_advanced '1'<br>
>>>Â Â Â Â option egress_ecn 'ECN'<br>
>>>Â Â Â Â option interface 'eth0.1'<br>
>>>Â Â Â Â option enabled '1'<br>
>>>Â Â Â Â option eqdisc_opts 'nat rtt 50000 bridged-ptm dual-dsthost diffserv4'<br>
>>>Â Â Â Â option upload '30000'<br>
>>>Â Â Â Â option linklayer 'ethernet'<br>
>>>Â Â Â Â option overhead '8'<br>
>>><br>
>>> Is the overhead correct? should i use the bridged-ptm keyword (or should i use pppoe-ptm).<br>
><br>
><br>
> Beware of using option linklayer ‘ethernet’ without option linklayer_advanced ‘1’ & option linklayer_adaptation_mechanism ‘default’. Or use linklayer ‘none’.<br>
<br>
</div></div>I guess "linklayer cake" would be better than none...<br></blockquote><div>Yes if i use link layer cake explicitly (option linklayer_advanced ‘1’ & option linklayer_adaptation_mechanism ‘cake’) it works better i.e. higher bandwidth with no effect on pings </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<span class="gmail-"><br>
> 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.<br>
<br>
</span>Â Â Â Â I agree, even though for ptm this is less dire than for ATM; still use linklayer default or linklayer cake.<br>
<span class="gmail-"><br>
><br>
> 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)<br>
<br>
</span>    I am beginning to wonder whether the attempt to hide complexity behind linklayer_advanced is not simply misguided and should be jettisoned...<br></blockquote><div>I agree i though that by leaving linklayer_advanced off i was allowing it to choose default i.e. cake! what about max_len below? is that ok?</div><div><br></div><div><div>qdisc cake 802b: dev eth0.1 root refcnt 2 bandwidth 30Mbit diffserv3 dual-dsthost nat rtt 50.0ms noatm overhead 30 via-ethernet total_overhead 30 hard_header_len 14 mpu 64</div><div> Sent 169756771 bytes 121528 pkt (dropped 4732, overlimits 118063 requeues 0)</div><div> backlog 8352b 6p requeues 0</div><div> memory used: 80640b of 4Mb</div><div> capacity estimate: 30Mbit</div><div>          Bulk Best Effort    Voice</div><div> thresh    1875Kbit    30Mbit   7500Kbit</div><div> target     9.7ms    2.5ms    2.5ms</div><div> interval    57.2ms    50.0ms    50.0ms</div><div> pk_delay     0us    3.2ms    1.6ms</div><div> av_delay     0us    2.3ms    283us</div><div> sp_delay     0us    324us     18us</div><div> pkts        0    125657     609</div><div> bytes        0  176142105    205486</div><div> way_inds      0      0      0</div><div> way_miss      0      61      2</div><div> way_cols      0      0      0</div><div> drops        0     4732      0</div><div> marks        0      0      0</div><div> ack_drop      0      0      0</div><div> sp_flows      0      0      0</div><div> bk_flows      0      1      0</div><div> un_flows      0      0      0</div><div> max_len       0     3012     2032</div><div><br></div><div>qdisc cake 8029: dev eth0.2 root refcnt 2 bandwidth 2440Kbit diffserv3 dual-srchost nat rtt 50.0ms noatm overhead 30 via-ethernet total_overhead 30 hard_header_len 14 mpu 64</div><div> Sent 7184293 bytes 74928 pkt (dropped 99, overlimits 46203 requeues 0)</div><div> backlog 54b 1p requeues 0</div><div> memory used: 155232b of 4Mb</div><div> capacity estimate: 2440Kbit</div><div>          Bulk Best Effort    Voice</div><div> thresh   152496bit   2440Kbit   610Kbit</div><div> target    119.1ms    7.4ms    29.8ms</div><div> interval   238.3ms    54.9ms    77.3ms</div><div> pk_delay     0us    1.3ms    526us</div><div> av_delay     0us    272us     10us</div><div> sp_delay     0us     9us     10us</div><div> pkts        0    75018      10</div><div> bytes        0   7200943     1290</div><div> way_inds      0      1      0</div><div> way_miss      0      73      8</div><div> way_cols      0      0      0</div><div> drops        0      99      0</div><div> marks        0      0      0</div><div> ack_drop      0      0      0</div><div> sp_flows      0      1      0</div><div> bk_flows      0      1      0</div><div> un_flows      0      0      0</div><div> max_len       0     3008     288</div></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<span class="gmail-"><br>
<br>
<br>
><br>
>><br>
>>Â Â Â The overhead certainly seems confusing. Personally, I dislike the overhead related compound keywords like *-ptm and would recommend the following:<br>
>> 1) remove the bridged-ptm from the eqdisc/iqdisc fields<br>
>> 2) add "mpu 64" to the eqdisc/iqdisc fields<br>
>> 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).<br>
> 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.<br>
<br>
</span>Â Â Â Â And again, Kevin is correct; my rationale might have been faulty but the recommendation still was correct though ;)...<br>
<span class="gmail-"><br>
<br>
>> 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).<br>
>><br>
>> 4) tell us about your ISP and plan ;)<br>
>><br>
> Cheers,<br>
><br>
> Kevin D-B<br>
<br>
</span>Thanks for your input, as always very much appreciated!<br>
<br>
Best Regards<br>
<span class="gmail-HOEnZb"><font color="#888888">    Sebastian </font></span> </blockquote><div> </div><div>Thanks & regards</div><div>Mark </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="gmail-HOEnZb"><div class="gmail-h5">
<br>
><br>
> GPG fingerprint: 012C ACB2 28C6 C53E 9775Â 9123 B3A2 389B 9DE2 334A<br>
<br>
</div></div></blockquote></div><br></div></div>