[Cerowrt-devel] squash/ignore DSCP and mangle table questions

Wed Apr 22 05:19:08 EDT 2015

Hi leetminiwheat,

On Apr 22, 2015, at 02:28 , leetminiwheat <LeetMiniWheat at gmail.com> wrote:

> Correcton on P.S. section: 3 and 5t not 4 and 5t.

	This is confusing me ;)

> 
> also regarding my tc qdisc output: i clearly need to reboot or
> something to fix the duplicate IFBs after testing a bunch of QoS.

	You could also try to run /usb/lib/sqm/stop.sh $NAME_OF_THE_INTERFACE (so not ifb5gw00 but rather gw00) that hopefully cleans up the left, let me know how that works...

> I currently have to hand-mix the latest ones with Cero since I don't
> have an updated luci-sqm
> 

Please find attached the most recent sqm-scripts and the most recent luci-sqm (the relevant script) please copy sqm-cbi.lua to:
/usr/lib/lua/luci/model/cbi/sqm.lua and you should be as up to date as you can be. Make sure to also move all the files from the attached sqm-scripts folder to the matching folders on your cerowrt router; that should hopefully fix the leftover IFB issue to some degree (we currently do not clean up when an interface goes away, only when the interface gets upped again)

Best Regards
	Sebastian
-------------- next part --------------
A non-text attachment was scrubbed...
Name: sqm-cbi.lua
Type: application/octet-stream
Size: 8144 bytes
Desc: not available
URL: <https://lists.bufferbloat.net/pipermail/cerowrt-devel/attachments/20150422/dd94d85c/attachment-0002.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: sqm-scripts.zip
Type: application/zip
Size: 27965 bytes
Desc: not available
URL: <https://lists.bufferbloat.net/pipermail/cerowrt-devel/attachments/20150422/dd94d85c/attachment-0002.zip>
-------------- next part --------------
> 
> On Tue, Apr 21, 2015 at 8:19 PM, leetminiwheat <LeetMiniWheat at gmail.com> wrote:
>> Sorry this is getting a bit off-topic here.
>> 
>>> On Wed, Apr 15, 2015 at 5:05 AM, Sebastian Moeller <moeller0 at gmx.de> wrote:
>>> 
>>>> On Apr 15, 2015, at 03:35 , leetminiwheat <LeetMiniWheat at gmail.com> wrote:
>>> 
>>>> I assume tweaking ring parameters from default RX:128 and TX:32
>>>> doesn't matter anymore thenr?
>>> 
>>>        As far as I know we leave that alone, see: http://www.bufferbloat.net/projects/bloat/wiki/Linux_Tips:
>>> “Set the size of the ring buffer for the network interface
>>> 
>>> NOTE: THIS HACK IS NO LONGER NEEDED on many ethernet drivers in Linux 3.3, which has Byte Queue Limits instead, which does a far better job."
>>> 
>> I noticed Dave mentioned on a mailing list that changing tx ring still
>> does have some benefit, and his notes in debloat script suggest BQL
>> doesn't always work as implied.
>>> 
>>>> 
>>>>> [...]
>>>>> If you have time and netperf-wrapper it would be good to convince yourself and us again, that txqueuelen really does not matter for BQL’d interfaces by running RRUL tests with and without your modifications….
>> 
>> Thanks, after extensive RRUL testing.... I've come to the same
>> conclusion Dave did, that changing tx perameters just isn't worth it
>> and causes instability. I noticed on 120s tests my WAN connection
>> would reset with ath9k: pll_reg and latencies would skyrocket
>> thereafter. I don't quite have a producible error, but it seemed like
>> associating/diassociating wireless clients might be related to it
>> (with Revert "debloat: stop changing wifi qlen") but I was also
>> changing txring on ethernet for testing at 4, 8, 16, etc.
>> 
>> Also, I tested some custom HFSC+fq_codel qos scripts here:
>> https://github.com/zcecc22/qos-nxt
>> He defaults to 90% (meaning you have to adjust your b/w limits), and
>> the 2-bin codel doesn't seem to work very well. Seemed like an
>> interesting compromise between simple and simplest, but the results
>> were pretty terrible. I'd like to test CAKE more, but it seems
>> 3.10.50-1 doesn't have the required kernel support.
>> 
>> Recent changes in barrier breaker to txring seem pretty dumb, they
>> default to 256 txring now I believe, ticket here was closed with
>> "worksforme" https://dev.openwrt.org/ticket/13072 so I'm reluctant to
>> upgrade, plus I don't fully understand the extent of which Dave's
>> kernel hacks impact things. Closer inspection/comparison/diffs are
>> needed if I'm to upgrade and integrate Cero's tweaks.
>> 
>> Oddly enough, simplest.qos on WAN gives me better throughput/latency
>> at times (likely due to less overhead), but other times simple.qos is
>> doing what it should and giving more throughput and lower latency to
>> higher priority traffic. I seem to get better RRUL tests with LIMIT=
>> blank, and ILIMIT/ELIMIT set to auto which results in this:
>> 
>> qdisc fq_codel a: dev se00 root refcnt 2 limit 1514p flows 1024
>> quantum 1514 target 5.0ms interval 100.0ms ecn
>> qdisc htb 1: dev ge00 root refcnt 2 r2q 10 default 12
>> direct_packets_stat 0 direct_qlen 1000
>> qdisc fq_codel 110: dev ge00 parent 1:11 limit 1024p flows 1024
>> quantum 300 target 5.0ms interval 100.0ms ecn
>> qdisc fq_codel 120: dev ge00 parent 1:12 limit 1024p flows 1024
>> quantum 300 target 5.0ms interval 100.0ms ecn
>> qdisc fq_codel 130: dev ge00 parent 1:13 limit 1024p flows 1024
>> quantum 300 target 5.0ms interval 100.0ms ecn
>> qdisc ingress ffff: dev ge00 parent ffff:fff1 ----------------
>> qdisc mq 1: dev sw10 root
>> qdisc fq_codel 10: dev sw10 parent 1:1 limit 800p flows 1024 quantum
>> 500 target 10.0ms interval 100.0ms
>> qdisc fq_codel 20: dev sw10 parent 1:2 limit 800p flows 1024 quantum
>> 300 target 5.0ms interval 100.0ms ecn
>> qdisc fq_codel 30: dev sw10 parent 1:3 limit 1000p flows 1024 quantum
>> 300 target 5.0ms interval 100.0ms ecn
>> qdisc fq_codel 40: dev sw10 parent 1:4 limit 1000p flows 1024 quantum
>> 300 target 5.0ms interval 100.0ms
>> qdisc mq 1: dev sw00 root
>> qdisc fq_codel 10: dev sw00 parent 1:1 limit 800p flows 1024 quantum
>> 500 target 10.0ms interval 100.0ms
>> qdisc fq_codel 20: dev sw00 parent 1:2 limit 800p flows 1024 quantum
>> 300 target 5.0ms interval 100.0ms ecn
>> qdisc fq_codel 30: dev sw00 parent 1:3 limit 1000p flows 1024 quantum
>> 300 target 5.0ms interval 100.0ms ecn
>> qdisc fq_codel 40: dev sw00 parent 1:4 limit 1000p flows 1024 quantum
>> 300 target 5.0ms interval 100.0ms
>> qdisc htb 1: dev ifb4ge00 root refcnt 2 r2q 10 default 12
>> direct_packets_stat 0 direct_qlen 32
>> qdisc fq_codel 110: dev ifb4ge00 parent 1:11 limit 1024p flows 1024
>> quantum 500 target 5.0ms interval 100.0ms ecn
>> qdisc fq_codel 120: dev ifb4ge00 parent 1:12 limit 1024p flows 1024
>> quantum 1500 target 5.0ms interval 100.0ms ecn
>> qdisc fq_codel 130: dev ifb4ge00 parent 1:13 limit 1024p flows 1024
>> quantum 300 target 5.0ms interval 100.0ms ecn
>> qdisc htb 1: dev ifb4gw00 root refcnt 2 r2q 10 default 12
>> direct_packets_stat 0 direct_qlen 32
>> qdisc fq_codel 110: dev ifb4gw00 parent 1:11 limit 1024p flows 1024
>> quantum 500 target 10.3ms interval 105.3ms ecn
>> qdisc fq_codel 120: dev ifb4gw00 parent 1:12 limit 1024p flows 1024
>> quantum 1500 target 10.3ms interval 105.3ms ecn
>> qdisc fq_codel 130: dev ifb4gw00 parent 1:13 limit 1024p flows 1024
>> quantum 300 target 10.3ms interval 105.3ms ecn
>> 
>> image of RRUL 45s graph here with simple.qos, no tx changes, auto
>> LIMIT on FiOS 32/25 (30Mb/22.5Mb QoS): https://screencloud.net/v/tVV0
>> - looks pretty good to me, but I should set up more MARK or DSCP
>> classifications for my important/unimportant traffic. MARK is probably
>> a better idea since it won't unnecessarily mis-flag outgoing traffic.
>> I assume QOS_MARK_ge00 sees marks from other interfaces too.
>> 
>> I'm still unsure whether to apply simple/simplest to my secure
>> wireless or leave it alone, Dave's debloat script seems to have
>> wireless-specific optimizations when left on auto, does simple.qos
>> handle VO/VI/BE/BK queues as efficiently? I never top out my wireless
>> since it's used only for mobile phones anyways and I run HT20 which
>> seems to be more reliable/less latency. however my guest wifi I do
>> need to limit and segregate via firewall so I have it enabled.
>> 
>> P.S. I learned the hard way NEVER to enable port 4 on the switch,
>> results in broken ethernet. port4 is unused and likely internally
>> reserved for unknown purposes. I'm still trying to figure out how it
>> maps an interface to an actual port, since I'd like to assign a single
>> switch switch port to it's own subnet for my FiOS router instead of
>> having to use a secondary router to clone the ge00 interface on the
>> backend router to forward FiOS ports to the verizon/FiOS MOCA bridge
>> router in order for alerts to display on set-top boxes such as caller
>> ID. There has to be a way of doing this without needing 3 routers...
>> My current thoughts are to remove the port (port3 in this case) from
>> the switch and make a new switch config with just 4 and 5t and somehow
>> make a new interface on that for the FiOS router, but assigning the
>> same ip address as the default gateway/route from ge00 on that port
>> might confuse routing. More information on their rather complicated
>> and seemingly unnecessary config with a backend router is located
>> here: http://www.dslreports.com/faq/verizonfios/3.0_Networking#16710