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

[David Lang <david@lang.hm>]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 6229 bytes --]

On Mon, 23 Mar 2015, Dave Taht wrote:

> On Mon, Mar 23, 2015 at 9:17 AM, Sebastian Moeller <moeller0@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 have a few spare 3800s if some of you developers need one.

unfortunantly I don't have a fast connection to test on.

David Lang

> 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@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@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
> _______________________________________________
> Cerowrt-devel mailing list
> Cerowrt-devel@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cerowrt-devel