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

[Dave Taht]

On Mon, Mar 23, 2015 at 9:17 AM, Sebastian Moeller <moeller0 at gmx.de> wrote:
> Hi Dave,
>
> I take it policing is still not cutting it then

I didn't think it would, but I was looking for an illustrative example
to use as a cluebat on people that think policing works. I have a
string of articles to write
about so many different technologies...

... and I'd felt that maybe if I merely added ecn to an existing
policer I'd get a good result, just haven't - like so many things -
got round to it. I do have reasonable hopes for "bobbie", also...

>, and the “hunt” for a wndr3[7|8]000 is still on?

Yep. I figure we're gonna find an x86 box to do the higher end stuff
in the near term, unless one of the new dual a9 boxen works out.

> 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...

Well, the big part of the upgrade was from linux 3.10 to linux 3.18. I
got nearly 600mbit forwarding rates out of that (up from 340 or so) on
the wndr3800. I have not rebuilt those with the latest code, my goal
is to find *some* platform still being made to use, and the tplink has
the benefit of also doing ac...

IF you have a spare wndr3800 to reflash with what I built friday, goferit...

I think part of the bonus performance we are also getting out of cake
is in getting rid of a bunch of firewall and tc classification rules.

(New feature request for cake might be to do dscp squashing and get
rid of that rule...! I'd like cake to basically be a drop in
replacement for the sqm scripts.
 I wouldn't mind if it ended up being called sqm, rather than cake, in
the long run, with what little branding we have being used. Google for
"cake shaper"
if you want to get a grip on how hard marketing "cake" would be...)

.

>
> 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
>



-- 
Dave Täht
Let's make wifi fast, less jittery and reliable again!

https://plus.google.com/u/0/107942175615993706558/posts/TVX3o84jjmb