Re: [Cerowrt-devel] archer c7 v2, policing, hostapd, test openwrt build

[Dave Taht <dave.taht@gmail.com>]

htb and ingress shaping are the biggest problems yes.

On Sun, Mar 22, 2015 at 6:45 PM, David Lang <david@lang.hm> wrote:
> On Mon, 23 Mar 2015, Jonathan Morton wrote:
>
>>> On 23 Mar, 2015, at 02:24, Dave Taht <dave.taht@gmail.com> 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’t actually maintain a queue, but it is possible to
>> calculate when the currently-arriving packet would be scheduled for sending
>> 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 can
>> 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, hash
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’s no queue management, timer interrupts nor flow
>> segregation, the overhead should be significantly lower than an actual
>> queue.  And there’s 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



-- 
Dave Täht
Let's make wifi fast, less jittery and reliable again!

https://plus.google.com/u/0/107942175615993706558/posts/TVX3o84jjmb