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 89FEE21F40B for ; Wed, 3 Jun 2015 10:51:50 -0700 (PDT) Received: from [10.185.25.48] ([46.189.28.65]) by mail.gmx.com (mrgmx103) with ESMTPSA (Nemesis) id 0LymjL-1ZBd5j3Gml-016C0u; Wed, 03 Jun 2015 19:51:46 +0200 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: Wed, 3 Jun 2015 19:49:40 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <5A699476-8E71-4D38-BABE-F755931447B5@gmx.de> References: To: Aaron Wood X-Mailer: Apple Mail (2.1878.6) X-Provags-ID: V03:K0:O3KqA72VRYGXhuhgmvIGIznKSEj/1BjSwN4OGbpFI8ubvfiz511 a4aPyPvOLBpK6bdS91nsZ52gwWLllbi6TVPr8G55Ouq9osIvJHfa6jzOG8orArW80cwHTLU Ny9RVGqSk0qhhabOen/xXGlqOjRNK5/o7koPlcUxZQ0WHGRBZbKfPIwmkwxi6rdeC/MAn8f Ebi5ZFXpRzmMFc2vDN59g== X-UI-Out-Filterresults: notjunk:1;V01:K0:+JruTG6/qys=:X7Sm7+4FgC0pIX5+a5jojR fa090t7OBXxs73R7eGKoIxKNnoNO31sgrhQkgg2hDc9k5zDjudX0oL2pNKVTpoQesfESVq4Ti EdmsO+yxpDYWrzgX6oi+bQqXkdSF91qGLBofdWNif4gJJaSOBfBpU4XcK//kZSD3bpaiFvEK+ Gy6suSx+wzasF0TswIYnRERjpO3Nsm0ICCcRovE2pl9JtkzXdDxw5cjex+ZRXftWOucdnlHyK 0RyU28UwAWdLjPQDh+ZRt5RhjOZ6ehmrbizPcqbtyGsJ5YLbbedQ/FhJS4SKaqSEUCDjK6NLP kcS1Kgeg6m+v7NjsnDUhvUKWo2kAwDO5IAcLTKqeZ0NVsz0Mka0MlOFnBKUm+Fc3Fl/fmc4fr ZUyEjFSTpJ6jekMubaBuT12O4b7fYAj656WYARBFom3gAN/imvUa0TDjD3AmUOXzGNy6vehSl 0ktw0wopSZ+JpnMxs1HbVJpVMBRK+aVNKB3prXjzhTHwHL+3CGSWJRoG5Vaf9VovPKoQIDUes U4QSPmQCOHxyBPS2HZCJ54p3EWovoZ/qF7njUlpEzHuZPYrP5rE+9D9ql6Br1B0m/94nw+pkG +ZMBL+8g3onkHjrRuy4+O0LiaM4SNfGQCmM9hFhmQHP6etMYEDD4vr2iT2H4Lbtc4invLxxHM rwL6dlrMUye1sXKbaJxRic3rvvI5c9FjETd9bLQnO0Co4F4ziy2CnloyUSN/ZgD12beoYH2jl +K7C1qg2oUvM6huVD1GMl0KCaHpUS3G+/PauUpl5j35hjGSeRTdYvfAkIx5HHuAsBUaMD70pO e+yYW7Y Cc: cerowrt-devel Subject: Re: [Cerowrt-devel] ingress rate limiting falling short 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: Wed, 03 Jun 2015 17:52:19 -0000 HI Aaron, On Jun 3, 2015, at 07:45 , Aaron Wood wrote: > I wrote this up on my blog, where I can intersperse text and graphs a = bit better: >=20 > = http://burntchrome.blogspot.com/2015/06/htb-rate-limiting-not-quite-lining= -up.html >=20 > Basically, I ran a series of tcp_download tests, using increasing = ingress rates with sqm_scripts, and then used flent's box-plots to put = the results into a combined image for comparing. >=20 > On the 3800, it never meets the rate, but it's only off by maybe 5%. =20= As Jonathan pointed out already this is in the range of the = difference between raw rates and tcp good put, so nothing to write home = about ;) > But on my new WRT1900AC, it's wildly off, even over the same = performance range (I tested it from 80-220Mbps rates in 20Mbps jumps, = and saw from 40-150Mbps. So you started with the WRT1900AC where the wndr3800 dropped = off? I wonder maybe the Belkin is also almost linear for the lower = range? I also note we adjust the quantum based on the rates: from functions .sh: get_mtu() { BW=3D$2 F=3D`cat /sys/class/net/$1/mtu` if [ -z "$F" ] then F=3D1500 fi if [ $BW -gt 20000 ] then F=3D$(($F * 2)) fi if [ $BW -gt 30000 ] then F=3D$(($F * 2)) fi if [ $BW -gt 40000 ] then F=3D$(($F * 2)) fi if [ $BW -gt 50000 ] then F=3D$(($F * 2)) fi if [ $BW -gt 60000 ] then F=3D$(($F * 2)) fi if [ $BW -gt 80000 ] then F=3D$(($F * 2)) fi echo $F } which we use in the htb invocations via this indirection: LQ=3D"quantum `get_mtu $IFACE $CEIL`=94 $TC qdisc add dev $DEV root handle 1: `get_stab_string` htb default 12 $TC class add dev $DEV parent 1: classid 1:1 htb $LQ rate ${CEIL}kbit = ceil ${CEIL}kbit `get_htb_adsll_string` $TC class add dev $DEV parent 1:1 classid 1:10 htb $LQ rate ${CEIL}kbit = ceil ${CEIL}kbit prio 0 `get_htb_adsll_string` $TC class add dev $DEV parent 1:1 classid 1:11 htb $LQ rate 32kbit ceil = ${PRIO_RATE}kbit prio 1 `get_htb_adsll_string` $TC class add dev $DEV parent 1:1 classid 1:12 htb $LQ rate = ${BE_RATE}kbit ceil ${BE_CEIL}kbit prio 2 `get_htb_adsll_string` $TC class add dev $DEV parent 1:1 classid 1:13 htb $LQ rate = ${BK_RATE}kbit ceil ${BE_CEIL}kbit prio 3 `get_htb_adsll_string` So maybe we need to extend the quantum increases beyond 80Mbps to keep = things linear? I don=92t know but it sure looks suspicious=85 >=20 > I have no idea where to start looking for the cause. But for now, I'm = just setting my ingress rate MUCH higher than I should, because it's = working out to the right value as a result. It would be great to understand why we need to massively = under-shape in that situation to get decent shaping and decent latency = under load. Best Regards Sebastian >=20 > -Aaron > _______________________________________________ > Cerowrt-devel mailing list > Cerowrt-devel@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/cerowrt-devel