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

Tue Apr 21 20:28:42 EDT 2015

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

also regarding my tc qdisc output: i clearly need to reboot or
something to fix the duplicate IFBs after testing a bunch of QoS. I
currently have to hand-mix the latest ones with Cero since I don't
have an updated luci-sqm

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