[Cerowrt-devel] archer c7 v2, policing, hostapd, test openwrt build

[Sebastian Moeller]

Hi Dave,

I take it policing is still not cutting it then, and the “hunt” for a wndr3[7|8]000 is still on? It look the archer c7v2 does roughly twice as good as the old cerowrt reference model, a decent improvement, but not yet present-safe let alone future-safe...

Best  Regards
	Sebastian

On Mar 23, 2015, at 01:24 , Dave Taht <dave.taht at gmail.com> wrote:

> so I had discarded policing for inbound traffic management a long
> while back due to it not
> handling varying RTTs very well, the burst parameter being hard, maybe
> even impossible to tune, etc.
> 
> And I'd been encouraging other people to try it for a while, with no
> luck. So anyway...
> 
> 1) A piece of good news is - using the current versions of cake and
> cake2, that I can get on linux 3.18/chaos calmer, on the archer c7v2
> shaping 115mbit download with 12mbit upload... on a cable modem...
> with 5% cpu to spare. I haven't tried a wndr3800 yet...
> 
> htb + fq_codel ran out of cpu at 94mbit...
> 
> 2) On the same test rig I went back to try policing. With a 10k burst
> parameter, it cut download rates in half...
> 
> However, with a 100k burst parameter, on the rrul and tcp_download
> tests, at a very short RTT (ethernet) I did get full throughput and
> lower latency.
> 
> How to try it:
> 
> run sqm with whatever settings you want. Then plunk in the right rate
> below for your downlink.
> 
> tc qdisc del dev eth0 handle ffff: ingress
> tc qdisc add dev eth0 handle ffff: ingress
> tc filter add dev eth0 parent ffff: protocol ip prio 50 u32 match ip
> src 0.0.0.0/0 police rate 115000kbit burst 100k drop flowid :1
> 
> I don't know how to have it match all traffic, including ipv6
> traffic(anyone??), but that was encouraging.
> 
> However, the core problem with policing is that it doesn't handle
> different RTTs very well, and the exact same settings on a 16ms
> path.... cut download throughput by a factor of 10. - set to
> 115000kbit I got 16mbits on rrul.  :(
> 
> Still...
> 
> I have long maintained it was possible to build a better fq_codel-like
> policer without doing htb rate shaping, ("bobbie"), and I am tempted
> to give it a go in the coming months. However I tend to think
> backporting the FIB patches and making cake run faster might be more
> fruitful. (or finding faster hardware)
> 
> 3) There may be some low hanging fruit in how hostapd operates. Right
> now I see it chewing up cpu, and when running, costing 50mbit of
> throughput at higher rates, doing something odd, over and over again.
> 
> clock_gettime(CLOCK_MONOTONIC, {1240, 843487389}) = 0
> recvmsg(12, {msg_name(12)={sa_family=AF_NETLINK, pid=0,
> groups=00000000},
> msg_iov(1)=[{"\0\0\1\20\0\25\0\0\0\0\0\0\0\0\0\0;\1\0\0\0\10\0\1\0\0\0\1\0\10\0&"...,
> 16384}], msg_controllen=0, msg_flags=0}, 0) = 272
> clock_gettime(CLOCK_MONOTONIC, {1240, 845060156}) = 0
> clock_gettime(CLOCK_MONOTONIC, {1240, 845757477}) = 0
> _newselect(19, [3 5 8 12 15 16 17 18], [], [], {3, 928211}) = 1 (in
> [12], left {3, 920973})
> 
> I swear I'd poked into this and fixed it in cerowrt 3.10, but I guess
> I'll have to go poking through the patch set. Something involving
> random number obtaining, as best as I recall.
> 
> 4) I got a huge improvement in p2p wifi tcp throughput between linux
> 3.18 and linux 3.18 + the minstrel-blues and andrew's minimum variance
> patches - a jump of over 30% on the ubnt nanostation m5.
> 
> 5) Aside from that, so far the archer hasn't crashed on me, but I
> haven't tested the wireless much yet on that platform. My weekend's
> test build:
> 
> http://snapon.lab.bufferbloat.net/~cero3/ubnt/ar71xx/
> 
> 
> -- 
> Dave Täht
> Let's make wifi fast, less jittery and reliable again!
> 
> https://plus.google.com/u/0/107942175615993706558/posts/TVX3o84jjmb
> _______________________________________________
> Cerowrt-devel mailing list
> Cerowrt-devel at lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cerowrt-devel