> > On Tue, Apr 21, 2015 at 8:19 PM, leetminiwheat wrote: >> Sorry this is getting a bit off-topic here. >> >>> On Wed, Apr 15, 2015 at 5:05 AM, Sebastian Moeller wrote: >>> >>>> On Apr 15, 2015, at 03:35 , leetminiwheat 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