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

[Dave Taht]

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