Thank to both of you! On 17 December 2017 at 23:35, Sebastian Moeller wrote: > Hi Kevin, hi Mark, > > Kevin is 100% right! > > > 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 wrote: > >> > >> Hi Mark, > >> > >>> On Dec 17, 2017, at 11:45, Mark Captur 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’. > > I guess "linklayer cake" would be better than none... > 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 > > > 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... > 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? 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 Sent 169756771 bytes 121528 pkt (dropped 4732, overlimits 118063 requeues 0) backlog 8352b 6p requeues 0 memory used: 80640b of 4Mb capacity estimate: 30Mbit Bulk Best Effort Voice thresh 1875Kbit 30Mbit 7500Kbit target 9.7ms 2.5ms 2.5ms interval 57.2ms 50.0ms 50.0ms pk_delay 0us 3.2ms 1.6ms av_delay 0us 2.3ms 283us sp_delay 0us 324us 18us pkts 0 125657 609 bytes 0 176142105 205486 way_inds 0 0 0 way_miss 0 61 2 way_cols 0 0 0 drops 0 4732 0 marks 0 0 0 ack_drop 0 0 0 sp_flows 0 0 0 bk_flows 0 1 0 un_flows 0 0 0 max_len 0 3012 2032 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 Sent 7184293 bytes 74928 pkt (dropped 99, overlimits 46203 requeues 0) backlog 54b 1p requeues 0 memory used: 155232b of 4Mb capacity estimate: 2440Kbit Bulk Best Effort Voice thresh 152496bit 2440Kbit 610Kbit target 119.1ms 7.4ms 29.8ms interval 238.3ms 54.9ms 77.3ms pk_delay 0us 1.3ms 526us av_delay 0us 272us 10us sp_delay 0us 9us 10us pkts 0 75018 10 bytes 0 7200943 1290 way_inds 0 1 0 way_miss 0 73 8 way_cols 0 0 0 drops 0 99 0 marks 0 0 0 ack_drop 0 0 0 sp_flows 0 1 0 bk_flows 0 1 0 un_flows 0 0 0 max_len 0 3008 288 > > > > > >> > >> 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 Thanks & regards Mark > > > > > GPG fingerprint: 012C ACB2 28C6 C53E 9775 9123 B3A2 389B 9DE2 334A > >