From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ob0-x230.google.com (mail-ob0-x230.google.com [IPv6:2607:f8b0:4003:c01::230]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by huchra.bufferbloat.net (Postfix) with ESMTPS id 201AD21F27F for ; Mon, 23 Mar 2015 09:27:05 -0700 (PDT) Received: by obcjt1 with SMTP id jt1so106799879obc.2 for ; Mon, 23 Mar 2015 09:27:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=xsUv7CHTE+YT1EdYlMfnoMlpEopdYq3bAUVO6xHVyCo=; b=QglEi2/mKgpT8I5r5+q6gKofdynPkZHamn11SAMezmWghNrV4ymeCPxNN3xOS1kSgU qIlQ3jE5JGRnMdnITDpfkOmaJ69jt1LycPLyQafCTPN/MXLyC6pAK2qMP2jh4ke7bdUj 7sKXhuShc38+mTpzBiiPqGIPEOo2GC7ai+tUqSiGadCFwrKCZ/d+7npj6JlEiW59cQlY u+YxE3WXIzcjyHK+qDX7p3vyu450meQSBSZpHanic5sCG5YiAgyUfVwrHkp/fr2D38k2 hXcSK3eEx65VrpUfAYIu+1qqfH0bxe5pKZF9VprQuekSR8HiKOYa2aM17PyCTQA2gL+1 kY+g== MIME-Version: 1.0 X-Received: by 10.202.62.70 with SMTP id l67mr72237849oia.59.1427128024831; Mon, 23 Mar 2015 09:27:04 -0700 (PDT) Received: by 10.202.51.66 with HTTP; Mon, 23 Mar 2015 09:27:04 -0700 (PDT) In-Reply-To: <9E365ED1-1EDF-49A6-B01F-E24CB52CD702@gmx.de> References: <9E365ED1-1EDF-49A6-B01F-E24CB52CD702@gmx.de> Date: Mon, 23 Mar 2015 09:27:04 -0700 Message-ID: From: Dave Taht To: Sebastian Moeller Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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:27:34 -0000 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 =E2=80=9Chunt=E2=80=9D 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 ref= erence model, a decent improvement, but not yet present-safe let alone futu= re-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 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}) =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}) >> >> 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=C3=A4ht >> 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 > --=20 Dave T=C3=A4ht Let's make wifi fast, less jittery and reliable again! https://plus.google.com/u/0/107942175615993706558/posts/TVX3o84jjmb