From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-oi0-x232.google.com (mail-oi0-x232.google.com [IPv6:2607:f8b0:4003:c06::232]) (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 307F4208AD2; Wed, 27 May 2015 12:35:55 -0700 (PDT) Received: by oiww2 with SMTP id w2so15757135oiw.0; Wed, 27 May 2015 12:35:37 -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=NPsBZCAvkEhYLvTcH54QXA/qhzzotaHvarEoI+fJElU=; b=NAYLSoAx453bIjop5oXY02x7oJ2Ccm+YRjvFq9AFSiYwdMJ4bDaIe7XlOSW+r/P5k/ vKKiT27QY/git1zuegwyoRpsAZqwotwOp0GYcJCG/ryaF4MpNoyvHFgBi4lHBGXMs8bI ahGynuj2R3XP8vACwNKpwMdEyIw9KmJZecOqS74Bp7qIbDcBxrJpTfPzq5fKDGJ0Atxl 3U3aZ0zmvfCNzWd6RSAYnrhFTa/TzgRaXrIe5Dp84keua1D0jM7JBE6URgKxFw2XQT1t dnGY1ISXU29WneahGp5tXyXE4H134rg+Q2AA4OAzBjVEyvZNyXbOgk/vPd9uHOGNQBBl DBBA== MIME-Version: 1.0 X-Received: by 10.182.138.68 with SMTP id qo4mr27673482obb.56.1432755337791; Wed, 27 May 2015 12:35:37 -0700 (PDT) Received: by 10.202.105.146 with HTTP; Wed, 27 May 2015 12:35:37 -0700 (PDT) In-Reply-To: References: Date: Wed, 27 May 2015 12:35:37 -0700 Message-ID: From: Dave Taht To: Sebastian Moeller Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: cake@lists.bufferbloat.net, cerowrt-devel Subject: Re: [Cerowrt-devel] policer question 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, 27 May 2015 19:36:38 -0000 and in the end, that new modem crapped out completely On Wed, May 27, 2015 at 10:12 AM, Dave Taht wrote: > On Tue, May 26, 2015 at 3:49 AM, Sebastian Moeller wrot= e: >> Hi Dave, >> >> I just stumbled over your last edit of "wondershaper needs to go the way= of the dodo=E2=80=9D; especially the following caught my attention (lines = 303 - 311): >> >> ## The ingress policer doesn't work against ipv6, so if you have mixed t= raffic >> ## you are not matching all of it, and the policer fails entirely >> ## A correct, modern line for this would be: >> ## tc filter add dev ${DEV} parent ffff: protocol all match u32 0 0 \ >> ## police rate ${DOWNLINK}kbit burst 100k drop flowid :1 >> ## >> ## Even if it did work, the police burst size is too small for higher sp= eed >> ## connections and what I suggest above for a burst size needs to be >> ## a calculated figure.(that one works ok at 100mbit) >> >> I think we should implement a policer setting in SQM (if only for testin= g) so I wonder how to set the burst size? >> I think we basically can run the policer only X times per second, so we = should allow something along the lines of: >> bandwidth [bits/sec] / X [1/sec] =3D max bits in batch [bits] >> Since in the end, we only can work in bursts/batches we need to figure o= ut what worst-case batches to expect. >> Now it would be sweet if we could get a handle on X, but what about just= using the following approximation: >> >> How often does the policer run per second worst case? >> >> 100[kB]*1000*8 =3D 800000 [bit] >> (100*1000^2 [bit/sec] / (100*1000*8) [bit]) =3D 125 1/sec or 8 milliseco= nds per invocation >> >> So your example seems to show that if we can run 125 times per second we= will be able to drain enough packets so we do not drop excessively many pa= ckets. This bursting issue will increase the latency under load for sure, b= ut I guess not more than 8ms on average?. >> Now, I guess one issue will be that this is not simply dependent= on either data size or packet count, but probably we are both limited at h= ow many packets per second we can process as well as how many bytes. So wha= t about: >> >> burst =3D (bandwidth [bits/sec] / 125 [1/sec]) / (1000*8) [kB] >> >> This is probably too simplistic, but better than nothing. >> >> I would appreciate any hints how to improve this; so thanks in advance. = Now all I need to do is hook this up with sqm-scripts and then go test the = hell out of it ;) >> >> Best Regards >> Sebastian > > Well, I am pretty sure policing as currently understood is generally > not a win compared to inbound shaping with aqm, particularly in the > concatenated queues case which was the one I wanted to address (90/100 > rate differential). > > policers have generally been "pitched" as a means of customer > bandwidth control (with CIR and other "features"), and do seem to be > highly used... > > What I wanted to do was come up with a kinder, gentler policer that > was effective but less damaging to non-tcp-like flow types, and the > whole concept of a burst parameter just doesn't work with shorter RTTs > in particular when used with ewma. The initial burst characteristics > we see today are very different from the slow speeds and small initial > windows (2) of yesteryear, and we tend to see a bunch of flows in slow > start all at the same time. signal sent is too late to dissipate the > original burst, and yet the policer signal is a brick wall so once it > kicks in bad things happen to all flows. > > So, for example, I came up with a simple mod to the existing policer > code, to "shred" inbound with a fq-like idea The shred.patch and some > flent data are here: > > http://snapon.lab.bufferbloat.net/~cero3/bobbie/ > > But: new data points galore hit me at the same time. > > Recently I boosted my signal strength on my cable modems in the > biggest testbed, and switched to a new one. the old one, latched up at > 110mbit down prior (and really horrible download bufferbloat), started > giving me 172mbit service. This morning I measured that at about > 142mbit service. THAT difference in performance ended up pretty > dramatic, I went from where dslreports would peak at seconds on > inbound to mere 100s of ms on an unshaped modem. > > http://www.dslreports.com/speedtest/560968 > > dslreports changed their cable test to be 16 down and 12 up, also (from 1= 6/6). > > ( I have also made so many other changes to the test driving box - for > example I reduced tcp_limit_output_bytes to 4k and started using the > sch_fq qdisc on my test driver box - and certainly it is my hope that > the cable isps sat up and took notice and deployed some fixes in the > past few weeks) > > So here is me just fixing outbound on this test: > > http://www.dslreports.com/speedtest/560989 > > so there are WAY too many variables in play again. > > and trying to fix inbound (and failing) > > http://www.dslreports.com/speedtest/561097 > > (and see the dataset) > > I am still seeing 30ms of induced latency on the rrul test but it is > so far from horrible that I think I am still dreaming. > and i have a whole bunch of variables to tediously recheck. > >> >> >> >> > > > > -- > Dave T=C3=A4ht > Open Networking needs **Open Source Hardware** > > https://plus.google.com/u/0/+EricRaymond/posts/JqxCe2pFr67 --=20 Dave T=C3=A4ht What will it take to vastly improve wifi for everyone? https://plus.google.com/u/0/explore/makewififast