From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "mout.gmx.net", Issuer "TeleSec ServerPass DE-1" (verified OK)) by huchra.bufferbloat.net (Postfix) with ESMTPS id 0B8C921F27E for ; Mon, 23 Mar 2015 09:17:36 -0700 (PDT) Received: from hms-beagle.home.lan ([87.164.165.7]) by mail.gmx.com (mrgmx103) with ESMTPSA (Nemesis) id 0LbuIK-1ZJHAH3SgW-00jF2x; Mon, 23 Mar 2015 17:17:33 +0100 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Sebastian Moeller In-Reply-To: Date: Mon, 23 Mar 2015 17:17:32 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <9E365ED1-1EDF-49A6-B01F-E24CB52CD702@gmx.de> References: To: =?windows-1252?Q?Dave_T=E4ht?= X-Mailer: Apple Mail (2.1878.6) X-Provags-ID: V03:K0:sVrDAUFynAq8yRchZIxq7TBjcv2ma1NsEDh8zMbg1Dz3FjTeRHo fP1wGlbTkmIhGIvYLMs9Uu30y3d6JZSFPVJlTaSKg8mf9zca5VWgoOGjmJiDQyh4+9nOiFB GWSCoLJgzmQkUt4bNcD3hTZZIQ7nodHEVzirZTZL4e7oWeqy0wOhLhC2AQHBnd0O1OlMonT JuFYm1OivywSmyLTAttAg== X-UI-Out-Filterresults: notjunk:1; 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 16:18:05 -0000 Hi Dave, I take it policing is still not cutting it then, and the =93hunt=94 for = a wndr3[7|8]000 is still on? 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... 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. >=20 > And I'd been encouraging other people to try it for a while, with no > luck. So anyway... >=20 > 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... >=20 > htb + fq_codel ran out of cpu at 94mbit... >=20 > 2) On the same test rig I went back to try policing. With a 10k burst > parameter, it cut download rates in half... >=20 > 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. >=20 > How to try it: >=20 > run sqm with whatever settings you want. Then plunk in the right rate > below for your downlink. >=20 > 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 >=20 > I don't know how to have it match all traffic, including ipv6 > traffic(anyone??), but that was encouraging. >=20 > 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. :( >=20 > Still... >=20 > 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) >=20 > 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. >=20 > clock_gettime(CLOCK_MONOTONIC, {1240, 843487389}) =3D 0 > recvmsg(12, {msg_name(12)=3D{sa_family=3DAF_NETLINK, pid=3D0, > groups=3D00000000}, > = msg_iov(1)=3D[{"\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=3D0, msg_flags=3D0}, 0) =3D 272 > clock_gettime(CLOCK_MONOTONIC, {1240, 845060156}) =3D 0 > clock_gettime(CLOCK_MONOTONIC, {1240, 845757477}) =3D 0 > _newselect(19, [3 5 8 12 15 16 17 18], [], [], {3, 928211}) =3D 1 (in > [12], left {3, 920973}) >=20 > 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. >=20 > 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. >=20 > 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: >=20 > http://snapon.lab.bufferbloat.net/~cero3/ubnt/ar71xx/ >=20 >=20 > --=20 > Dave T=E4ht > Let's make wifi fast, less jittery and reliable again! >=20 > 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