htb and ingress shaping are the biggest problems yes. On Sun, Mar 22, 2015 at 6:45 PM, David Lang <[email protected]> wrote: > On Mon, 23 Mar 2015, Jonathan Morton wrote: > >>> On 23 Mar, 2015, at 02:24, Dave Taht <[email protected]> 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 _______________________________________________ Cerowrt-devel mailing list [email protected] https://lists.bufferbloat.net/listinfo/cerowrt-devel
