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

Tue Apr 21 20:19:34 EDT 2015

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