[Cerowrt-devel] wifi over narrow channels
https://www.usenix.org/system/files/conference/nsdi12/nsdi12-final142.pdf I've had 5mhz channels working in the ath9k at various points in cerowrt's lifetime. (using it for meshy stuff) After digesting most of the 802.11ac standard I do find myself wishing they'd gone towards narrower channels rather than wider. The netgear x4 defaults to a 160mhz wide channel. :sigh: The above paper has some nifty ideas in it. -- Dave Täht https://www.bufferbloat.net/projects/make-wifi-fast ___ Cerowrt-devel mailing list Cerowrt-devel@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/cerowrt-devel
Re: [Cerowrt-devel] wifi over narrow channels
IIRC only some of the ath9k radio's are able to do 5mhz channels - namely the enterprise chip variants. -Joel On 9 October 2014 11:14, Dave Taht dave.t...@gmail.com wrote: https://www.usenix.org/system/files/conference/nsdi12/nsdi12-final142.pdf I've had 5mhz channels working in the ath9k at various points in cerowrt's lifetime. (using it for meshy stuff) After digesting most of the 802.11ac standard I do find myself wishing they'd gone towards narrower channels rather than wider. The netgear x4 defaults to a 160mhz wide channel. :sigh: The above paper has some nifty ideas in it. -- Dave Täht https://www.bufferbloat.net/projects/make-wifi-fast ___ Cerowrt-devel mailing list Cerowrt-devel@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/cerowrt-devel ___ Cerowrt-devel mailing list Cerowrt-devel@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/cerowrt-devel
Re: [Cerowrt-devel] [OpenWrt-Devel] [RFC PATCH] packages: Smart Queue Management for AQM Packet Scheduling and Qos from CeroWrt
How good is the throughput on CeroWrt compared to OpenWrt ? On Oct 2, 2014 9:55 AM, Dave Taht dave.t...@bufferbloat.net wrote: On Wed, Oct 01, 2014 at 12:10:46PM -0400, Weedy wrote: On 30/03/14 06:29 PM, Dave Taht wrote: On Sun, Mar 30, 2014 at 02:24:44PM -0400, Weedy wrote: On Sat, Mar 29, 2014 at 2:56 PM, Dave Täht dave.t...@bufferbloat.net wrote: From: Dave Taht dave.t...@bufferbloat.net This adds support for the bufferbloat project's Smart Queue Management (SQM) system, which improves over openwrt's qos-scripts in the following ways + Uses HTB with two models for managing traffic a simplest one that merely uses fq_codel, and a three tier one that does some basic and tunable packet prioritization. + Works with ipv6 and ipv4 correctly (unlike qos-scripts) + extensive support for fixing ADSL and PPOe framing problems + Partial support for key diffserv markings + highly tuned fq_codel implementation especially for low bandwidths + Tested heavily on cable modems and on dsl devices It is a disimprovement in that: - There are no built-in tricks for doing l7 classification, or other forms of packet inspection. - We haven't explored hfsc all that much, prefering to rely on the predictable behavior of htb + fq_codel for everything - And there is support for a few qdiscs that are not in the linux kernel mainline that remain experimental. --- net/sqm-scripts/Makefile | 48 +++ net/sqm-scripts/files/etc/config/sqm | 11 + net/sqm-scripts/files/etc/init.d/sqm | 23 ++ net/sqm-scripts/files/usr/lib/sqm/functions.sh | 335 net/sqm-scripts/files/usr/lib/sqm/run.sh | 67 net/sqm-scripts/files/usr/lib/sqm/simple.qos | 187 +++ net/sqm-scripts/files/usr/lib/sqm/simple.qos.help |1 + net/sqm-scripts/files/usr/lib/sqm/simplest.qos | 84 + .../files/usr/lib/sqm/simplest.qos.help|1 + net/sqm-scripts/files/usr/lib/sqm/stop.sh | 22 ++ 10 files changed, 779 insertions(+) create mode 100644 net/sqm-scripts/Makefile create mode 100644 net/sqm-scripts/files/etc/config/sqm create mode 100755 net/sqm-scripts/files/etc/init.d/sqm create mode 100644 net/sqm-scripts/files/usr/lib/sqm/functions.sh create mode 100755 net/sqm-scripts/files/usr/lib/sqm/run.sh create mode 100755 net/sqm-scripts/files/usr/lib/sqm/simple.qos create mode 100644 net/sqm-scripts/files/usr/lib/sqm/simple.qos.help create mode 100755 net/sqm-scripts/files/usr/lib/sqm/simplest.qos create mode 100644 net/sqm-scripts/files/usr/lib/sqm/simplest.qos.help create mode 100755 net/sqm-scripts/files/usr/lib/sqm/stop.sh diff --git a/net/sqm-scripts/files/etc/config/sqm b/net/sqm-scripts/files/etc/config/sqm new file mode 100644 index 000..547d321 --- /dev/null +++ b/net/sqm-scripts/files/etc/config/sqm @@ -0,0 +1,11 @@ + +config queue 'ge00' +option enabled '0' +option interface 'ge00' +option download '2' +option upload '4000' +option qdisc 'fq_codel' +option script 'simple.qos' +option qdisc_advanced '0' +option linklayer 'none' + How hard is this to config from the command line/vim? There are a few more options than this (for DSL compensation, ecn and advanced configuration), the above would work if you changed enabled to '1' and the device from ge00 to your wan device. (not the wan firewall rule, presently. ) It does help to have a sane long term and realistic measurement of your network using something like the rrul test rather than the oft-gamed speedtest. http://www.bufferbloat.net/projects/cerowrt/wiki/Setting_up_SQM_for_CeroWrt_310 You are right, we should fully document all the variables in this file. Until recently they were kind of in flux. I've never needed or really wanted luci on my box, I just use vim. Going by this patch, there is either nothing to config or no examples. I would think shipping a roughly equivalent config to what ships in qos-scripts would be a good start to get people testing. /etc/init.d/sqm start,stop etc work as expected. IE: highest priority: small ARP, DNS, and SSH packets The SQM default is local DNS and ntp. fq_codel automagically optimizes for other sparse flows like arp, ssh, mosh, tcp syn, synack, etc, no need to do that via classification. normal: HTTP, HTTPS So you want to deprioritize vpn, smtp, rsync, dropbox, http on odd ports, caching servers, etc, all in favor of the web gods? we just toss all that into the normal (best effort bin) and let fq_codel sort it out. bulk: everything else. We do respect the diffserv marking of CS1
Re: [Cerowrt-devel] possible ingress shaping bug?
On Mon, Oct 6, 2014 at 3:07 AM, Richard Edmands thesir...@gmail.com wrote: Greetings Everyone! As part of research into a related part of the kernel we ran across an oddity with nfct on ifb devices. To give weight to the existence of the oddity, a Debian Jessie (so 3.16.3 based kernel) system was setup with wan and lan ports. A modified version of the gentoo fq_codel script was used (Wan is eth0 and associated IFB is ifb0). Including script. The kernel had 2 printk's inserted (see included change to cls_flows.c) to print out the ip addresses which were being returned to the flows process for nfct-src and nfct-dst. The nfct-src attached to eth0 printk was heard from, it returned the right answers and some nonsense as expected. The nfct-dst attached to ifb0 printk didn't return a thing, not even nonsense. -- (Wild speculation) Maybe the conntrack lookup only works correctly from the right device? so the lookup from the packet on ifb0 is being looked up in conntrack as if it should relate to a connection on ifb0 instead of a connection on eth0? does straight src or dst work in ifb? The conntrack stuff is long gone by the time you get to ifb. --- #!/bin/sh ## Paths and definitions tc=/sbin/tc IPT=iptables #The interface name of the internet link ext=eth0 #Ignore this ext_ingress=ifb0 # Set these as per your adsl sync rate, at 90% to start with, modify up and down until the tests work. ext_up=4kbit ext_down=4kbit ethtool -K eth0 tso off gro off gso off ethtool -K eth1 tso off gro off gso off modprobe ifb modprobe sch_fq_codel modprobe act_mirred modprobe cls_flow # Clear old queuing disciplines (qdisc) on the interfaces $tc qdisc del dev $ext root $tc qdisc del dev $ext ingress $tc qdisc del dev $ext_ingress root $tc qdisc del dev $ext_ingress ingress # # INGRESS # # Create ingress on external interface $tc qdisc add dev $ext handle : ingress ifconfig $ext_ingress up # if the interace is not up bad things happen # Forward all ingress traffic to the IFB device $tc filter add dev $ext parent : protocol all u32 match u32 0 0 action mirred egress redirect dev $ext_ingress # Create an EGRESS filter on the IFB device #You can play with the r2q value, higher for faster links, lower for slower. FIXME? Totally need some maths and tables for the correct values in various situations. Is being too high safer than being too low? It is best to be correct. See the sqm source code and recent threads on this list. *I* don't grok all that is involved on getting dsl or PPPoe right, all the systems I have access to are cable or fiber. $tc qdisc add dev $ext_ingress root handle 1: htb default 12 r2q 5 # Add root class HTB with rate limiting $tc class add dev $ext_ingress parent 1: classid 1:1 htb rate $ext_down overhead 40 mtu 1492 mpu 53 linklayer atm $tc class add dev $ext_ingress parent 1:1 classid 1:11 htb rate $ext_down prio 0 overhead 40 mtu 1492 mpu 53 linklayer atm $tc class add dev $ext_ingress parent 1:1 classid 1:12 htb rate $ext_down prio 0 overhead 40 mtu 1492 mpu 53 linklayer atm #This is where fq_codel is installed for downlink traffic $tc qdisc add dev $ext_ingress parent 1:11 fq_codel noecn target 50ms interval 300ms quantum 512 flows 1024 limit 3000 $tc qdisc add dev $ext_ingress parent 1:12 fq_codel noecn target 50ms interval 300ms quantum 512 flows 1024 limit 3000 #FIXME? Really need to find/have a discussion and determine good values for this $tc filter add dev $ext_ingress protocol ip parent 1: handle 11 flow hash keys nfct-dst divisor 1024 baseclass 1:11 $tc filter add dev $ext_ingress protocol ip parent 1: handle 12 flow hash keys nfct-dst divisor 1024 baseclass 1:12 dst is the correct thing here. # Yes I KNOW this does not work. $tc filter add dev $ext_ingress protocol ip parent 1: prio 2 u32 match ip dst 172.30.200.2 flowid 1:11 Well, actually no, this should work. Unless the parent should be something else. # # EGRESS # # Add FQ_CODEL to EGRESS on external interface #You can play with the r2q value, higher for faster links, lower for slower. FIXME? Totally need some maths and tables for the correct values in various situations. Is being too high safer than being too low? $tc qdisc add dev $ext root handle 1: htb default 12 r2q 1 # Add root class HTB with rate limiting $tc class add dev $ext parent 1: classid 1:1 htb rate $ext_up overhead 40 mtu 1492 mpu 53 linklayer atm $tc class add dev $ext parent 1:1 classid 1:11 htb rate 70kbit ceil $ext_up overhead 40 mtu 1492 mpu 53 linklayer atm $tc class add dev $ext parent 1:1 classid 1:12 htb rate 30kbit ceil $ext_up overhead 40 mtu 1492 mpu 53 linklayer atm #This is where fq_codel is installed for uplink traffic
Re: [Cerowrt-devel] [OpenWrt-Devel] [RFC PATCH] packages: Smart Queue Management for AQM Packet Scheduling and Qos from CeroWrt
On Wed, Oct 08, 2014 at 11:10:46PM +0300, Hannu Nyman wrote: Dave Taht wrote on Thu Oct 2 03:49:15 CEST 2014: So I don't know where to go. Certainly I'd like to see the battle hardened sqm scripts (which are more flexible than the C code above) get more widely used and in BB. SQM seems to work ok with the current Chaos Calmer trunk. Well, for now... I'd expect the delta to break eventually... I have included your SQM in my trunk WNDR3700/3800 community build ( https://forum.openwrt.org/viewtopic.php?id=28392 ) and it works ok. Arokh has also picked it up for his build ( https://forum.openwrt.org/viewtopic.php?id=50914 ). So you might get more feedback sooner or later, if users of our builds really do try it. Excellent. I'd *really* like to get some testers doing ingress shaping at above 60-80mbits, which seems to be a brick wall we've hit on the ar71xx and octeon, on other platforms like the arm and x86. A tool we use a lot is netperf-wrapper. I feel that the best way to get wider testing and real-life usage for SQM would be to create a pull request in the new packages feed in Github, to get both the SQM itself and the Luci frontend included there. Being available in the packages feed would create more interest for the package. If it proves to work ok, the devs might then import it into the core Openwrt repo (where the old qos-scripts is). I went to sleep pre BBrc1. I woke up, and everything was in github. It's still not clear to me how I'd build cero from frozen BB sources, rather than the evolving github packages. Ps. For my own build I made a slight modification to the Luci menu item, as pure SQM does not say much. I changed it to SQM QoS. Yes, SQM by itself doesn't mean enough. ___ Cerowrt-devel mailing list Cerowrt-devel@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/cerowrt-devel
