From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ob0-x22a.google.com (mail-ob0-x22a.google.com [IPv6:2607:f8b0:4003:c01::22a]) (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 9B09921F265 for ; Sun, 22 Mar 2015 19:00:23 -0700 (PDT) Received: by obdfc2 with SMTP id fc2so113339416obd.3 for ; Sun, 22 Mar 2015 19:00:23 -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=D3AqrJbnBmQ0+qfpUyAavfCdXsFZST13RgkwZ44R/rE=; b=bNLV+nJVd8RlPY9+TcJZJyVrQTR0L+wOnBJG18OO6UVZv6++iVy2OKVbjDU0C3uEqG hKyMwqyRDAMvqIluv0kmcT/r02np1q41FBcoqO6QkBWhp3LLSSgH7lfpddF6lvZrEgGD uvepasOPLtJ96WRFvAU+XN9du/xCuQ41dNVzK78fw01v4WUXE//z2GuauSp1eWw1lTJ5 Jt5RYdhQpHKWqNcvYRUaSiTME/NfDQFyxflUdt8Z0oPPL8UjZYSeES3OGEwXVljCHHJ+ MfItc0P+SaARVAyZXVseG77uE7nSIMbGZfHidsmfeWi56J2fYCv3JkQq1E8350KJAQ/b KPhA== MIME-Version: 1.0 X-Received: by 10.60.77.38 with SMTP id p6mr1845968oew.75.1427076023149; Sun, 22 Mar 2015 19:00:23 -0700 (PDT) Received: by 10.202.51.66 with HTTP; Sun, 22 Mar 2015 19:00:23 -0700 (PDT) In-Reply-To: References: <08BAF198-87C5-42B8-8899-53F34E47156E@gmail.com> Date: Sun, 22 Mar 2015 19:00:23 -0700 Message-ID: From: Dave Taht To: David Lang Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Jonathan Morton , "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 02:00:53 -0000 htb and ingress shaping are the biggest problems yes. On Sun, Mar 22, 2015 at 6:45 PM, David Lang wrote: > On Mon, 23 Mar 2015, Jonathan Morton wrote: > >>> On 23 Mar, 2015, at 02:24, Dave Taht wrote: >>> >>> 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. >> >> >> I have a hazy picture in my mind, now, of how it could be made to work. >> >> A policer doesn=E2=80=99t actually maintain a queue, but it is possible = to >> calculate when the currently-arriving packet would be scheduled for send= ing >> if a shaped FIFO was present, in much the same way that cake actually >> performs such scheduling at the head of a real queue. The difference >> between that time and the current time is a virtual sojourn time which c= an >> be fed into the Codel algorithm. Then, when Codel says to drop a packet= , >> you do so. 1) Sorta. See act_police for how it is presently done. The code is chock full of locks that I don't think are needed, and very crufty and old. >From a control theory perspective, we are aiming for a target *rate* rather than a target *delay*, but we can use the same codel like methods to try to achieve that rate - hit flows once over a calculated interval, decrease the interval if it doesn't = work. on top of that you don't want to brick wall things but you do want to identify and only hit once individual flows, so once you go into drop(or mark) mode, has= h the 5 tuple, store the tuple + time in a small ring buffer, hit a bunch of flows, but never 2 packets from the same flow in a row. keep a longer term rate (bytes/200ms) and a short term rate (say bytes/20ms) to bracket what you need, keep track of how much you exceeded the set rate for how long... and it seemed doable to do it without inducing delays, but "bobbing" up and down around the set rate at a level that would not induce much extra latency on the download on reasonable timescales. Still seemed like a lot of work for potentially no gain, at the time I was thinking about it hard. Couldn't figure out how to stably grown and shrink the size of the needed ring buffer to hit flows with... Decided I'd rather go profile where we were going wrong, profiling was broken, got burned out on it all. Thought my first step would be to add an ecn mode to act_police and see what happened. 2) I'd really like to get rid of the needed act_mirred stuff and be able to attach a true shaping qdisc directly to the ingress portion of the qdisc. 3) /me has more brain cells working than he did 9 months ago. >> Because there=E2=80=99s no queue management, timer interrupts nor flow >> segregation, the overhead should be significantly lower than an actual >> queue. And there=E2=80=99s a reasonable hope that involving Codel will = give better >> results than either a brick-wall or a token bucket. > > > are we running into performance issues with fq_codel? I thought all the > problems were with HTB or ingress shaping. > > David Lang --=20 Dave T=C3=A4ht Let's make wifi fast, less jittery and reliable again! https://plus.google.com/u/0/107942175615993706558/posts/TVX3o84jjmb