<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>