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 <[email protected]> wrote: > Sorry this is getting a bit off-topic here. > >> On Wed, Apr 15, 2015 at 5:05 AM, Sebastian Moeller <[email protected]> wrote: >> >>> On Apr 15, 2015, at 03:35 , leetminiwheat <[email protected]> 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 _______________________________________________ Cerowrt-devel mailing list [email protected] https://lists.bufferbloat.net/listinfo/cerowrt-devel
