Re: [Codel] codel "oversteer"

[Jonathan Morton <chromatix99@gmail.com>]

Is the cwnd also oscillating wildly or is it just an artefact of the visible part of the queue only being a fraction of the real queue?

Are ACK packets being aggregated by wireless? That would be a good explanation for large bursts that flood the buffer, if the rwnd opens a lot suddenly. This would also be an argument that 2*n is too small for the ECN drop threshold. 

The key to knowledge is not to rely on others to teach you it. 

On 20 Jun 2012, at 04:32, Dave Taht <dave.taht@gmail.com> wrote:

> I've been forming a theory regarding codel behavior in some
> pathological conditions. For the sake of developing the theory I'm
> going to return to the original car analogy published here, and add a
> new one - "oversteer".
> 
> Briefly:
> 
> If the underlying interface device driver is overbuffered, when the
> packet backlog finally makes it into the qdisc layer, that bursts up
> rapidly and codel rapidly ramps up it's drop strategy, which corrects
> the problem, but we are back in a state where we are, as in the case
> of an auto on ice, or a very loose connection to the steering wheel,
> "oversteering" because codel is actually not measuring the entire
> time-width of the queue and unable to control it well, even if it
> could.
> 
> What I observe on wireless now with fq_codel under heavy load is
> oscillation in the qdisc layer between 0 length queue and 70 or more
> packets backlogged, a burst of drops when that happens, and far more
> drops than ecn marks that I expected  (with the new (arbitrary) drop
> ecn packets if > 2 * target idea I was fiddling with illustrating the
> point better, now). It's difficult to gain further direct insight
> without time and packet traces, and maybe exporting more data to
> userspace, but this kind of explains a report I got privately on x86
> (no ecn drop enabled), and the behavior of fq_codel on wireless on the
> present version of cerowrt.
> 
> (I could always have inserted a bug, too, if it wasn't for the private
> report and having to get on a plane shortly I wouldn't be posting this
> now)
> 
> Further testing ideas (others!) could try would be:
> 
> Increase BQL's setting to over-large values on a BQL enabled interface
> and see what happens
> Test with an overbuffered ethernet interface in the first place
> Improve the ns3 model to have an emulated network interface with
> user-settable buffering
> 
> Assuming I'm right and others can reproduce this, this implies that
> focusing much harder on BQL and overbuffering related issues on the
> dozens? hundreds? of non-BQL enabled ethernet drivers is needed at
> this point. And we already know that much more hard work on fixing
> wifi is needed.
> 
> Despite this I'm generally pleased with the fq_codel results over
> wireless I'm currently getting from today's build of cerowrt, and
> certainly the BQL-enabled ethernet drivers I've worked with (ar71xx,
> e1000) don't display this behavior, neither does soft rate limiting
> using htb - instead achieving a steady state for the packet backlog,
> accepting bursts, and otherwise being "nice".
> 
> -- 
> Dave Täht
> SKYPE: davetaht
> http://ronsravings.blogspot.com/
> _______________________________________________
> Codel mailing list
> Codel@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/codel