On Mon, 23 Mar 2015, Dave Taht wrote: > On Mon, Mar 23, 2015 at 9:17 AM, Sebastian Moeller 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 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