From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ob0-x231.google.com (mail-ob0-x231.google.com [IPv6:2607:f8b0:4003:c01::231]) (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 9396221F164; Wed, 27 May 2015 10:12:18 -0700 (PDT) Received: by obew15 with SMTP id w15so12801523obe.1; Wed, 27 May 2015 10:12:15 -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=aSxYBT89OZQt2sU8GAt1iaEq1zjt01S9bS3F4OdJdBY=; b=olsNSnZEvBgC0Eu6BPxvPBmTcQRsPVjab3hICwj8nnYTiTg2FOb/so/cOWaBw+QcrJ SN5EZNXTVFFoYA7Cvb3BsCnFAJfmVz8bQgCIUt7BhRrCZMZSKWEGW4nzpXlvtBKreqMV VejF5tmPQ9tbDChB8MU3PXW8wQz6ahbAidckU2aHntpxrUoR77m8ahksz7CjsJaw8aoK XFZtv58c7wXvtDM7II396Yl51TkYmB4U50PTgDtC+wzghEh7ZLzcKRrgdhpgGwDTtLN1 UAiGFmmKO4/kXRdzS/7XGywjXRs6vxFVnZpn8ZtceSxX+AlM4pZ64dtClrlDgkGjmcoG VT2Q== MIME-Version: 1.0 X-Received: by 10.202.71.20 with SMTP id u20mr8369646oia.81.1432746735439; Wed, 27 May 2015 10:12:15 -0700 (PDT) Received: by 10.202.105.146 with HTTP; Wed, 27 May 2015 10:12:15 -0700 (PDT) In-Reply-To: References: Date: Wed, 27 May 2015 10:12:15 -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 17:12:53 -0000 On Tue, May 26, 2015 at 3:49 AM, Sebastian Moeller wrote: > 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 3= 03 - 311): > > ## The ingress policer doesn't work against ipv6, so if you have mixed tr= affic > ## 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 spe= ed > ## 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 testing= ) so I wonder how to set the burst size? > I think we basically can run the policer only X times per second, so we s= hould 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 ou= t 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 millisecon= ds 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 pac= kets. This bursting issue will increase the latency under load for sure, bu= t 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 ho= w many packets per second we can process as well as how many bytes. So what= 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. N= ow all I need to do is hook this up with sqm-scripts and then go test the h= ell 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 16/= 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. > > > > --=20 Dave T=C3=A4ht Open Networking needs **Open Source Hardware** https://plus.google.com/u/0/+EricRaymond/posts/JqxCe2pFr67