From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from bifrost.lang.hm (mail.lang.hm [64.81.33.126]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by huchra.bufferbloat.net (Postfix) with ESMTPS id EC70321F0D3 for ; Mon, 23 Mar 2015 10:07:56 -0700 (PDT) Received: from asgard.lang.hm (asgard.lang.hm [10.0.0.100]) by bifrost.lang.hm (8.13.4/8.13.4/Debian-3) with ESMTP id t2NH7mPP031213; Mon, 23 Mar 2015 09:07:48 -0800 Date: Mon, 23 Mar 2015 10:07:48 -0700 (PDT) From: David Lang X-X-Sender: dlang@asgard.lang.hm To: Dave Taht In-Reply-To: Message-ID: References: <9E365ED1-1EDF-49A6-B01F-E24CB52CD702@gmx.de> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="680960-1227086169-1427130468=:391" Cc: "cerowrt-devel@lists.bufferbloat.net" Subject: Re: [Cerowrt-devel] archer c7 v2, policing, hostapd, test openwrt build X-BeenThere: cerowrt-devel@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list List-Id: Development issues regarding the cerowrt test router project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Mar 2015 17:08:25 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --680960-1227086169-1427130468=:391 Content-Type: TEXT/PLAIN; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8BIT 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 --680960-1227086169-1427130468=:391--