<font face="arial" size="2"><p style="margin:0;padding:0;">One further thought - the time constants may well be adjusted so that there is what we in radio call an impedance mismatch (I mean it literally, not metaphorically) such that there is an SWR much greater than 1.  In an antenna feedline this results in oscillations of power that travel back and forth between transmitter and antenna, resulting in pulsating power delivered to the antenna.</p>
<p style="margin:0;padding:0;"> </p>
<p style="margin:0;padding:0;">Do you know the time constants of the TCP source congestion control algorithm (frequency of the "sawtooth" that arrives when there is a short queue) and the codel control loop?  If they are really different, you get a significant "beat frequency" between the two oscillators.   This would directly create the observed phenomenon.</p>
<p style="margin:0;padding:0;"> </p>
<p style="margin:0;padding:0;">I think you can probably tune one natural frequency or the other until there is an impedance match,  and then the codel damping should work.</p>
<p style="margin:0;padding:0;"> </p>
<p style="margin:0;padding:0;">Maybe this could be simulated in a simple simulator that models the situation to see if this is "normal" given the parameters, or whether it is a logic bug in one implementation or the other.</p>
<p style="margin:0;padding:0;"> </p>
<p style="margin:0;padding:0;">-----Original Message-----<br />From: "Dave Taht" <dave.taht@gmail.com><br />Sent: Tuesday, June 19, 2012 9:32pm<br />To: codel@lists.bufferbloat.net, cerowrt-devel@lists.bufferbloat.net<br />Subject: [Cerowrt-devel] codel "oversteer"<br /><br /></p>
<div id="SafeStyles1340160863">
<p style="margin:0;padding:0;">I've been forming a theory regarding codel behavior in some<br />pathological conditions. For the sake of developing the theory I'm<br />going to return to the original car analogy published here, and add a<br />new one - "oversteer".<br /><br />Briefly:<br /><br />If the underlying interface device driver is overbuffered, when the<br />packet backlog finally makes it into the qdisc layer, that bursts up<br />rapidly and codel rapidly ramps up it's drop strategy, which corrects<br />the problem, but we are back in a state where we are, as in the case<br />of an auto on ice, or a very loose connection to the steering wheel,<br />"oversteering" because codel is actually not measuring the entire<br />time-width of the queue and unable to control it well, even if it<br />could.<br /><br />What I observe on wireless now with fq_codel under heavy load is<br />oscillation in the qdisc layer between 0 length queue and 70 or more<br />packets backlogged, a burst of drops when that happens, and far more<br />drops than ecn marks that I expected  (with the new (arbitrary) drop<br />ecn packets if > 2 * target idea I was fiddling with illustrating the<br />point better, now). It's difficult to gain further direct insight<br />without time and packet traces, and maybe exporting more data to<br />userspace, but this kind of explains a report I got privately on x86<br />(no ecn drop enabled), and the behavior of fq_codel on wireless on the<br />present version of cerowrt.<br /><br />(I could always have inserted a bug, too, if it wasn't for the private<br />report and having to get on a plane shortly I wouldn't be posting this<br />now)<br /><br />Further testing ideas (others!) could try would be:<br /><br />Increase BQL's setting to over-large values on a BQL enabled interface<br />and see what happens<br />Test with an overbuffered ethernet interface in the first place<br />Improve the ns3 model to have an emulated network interface with<br />user-settable buffering<br /><br />Assuming I'm right and others can reproduce this, this implies that<br />focusing much harder on BQL and overbuffering related issues on the<br />dozens? hundreds? of non-BQL enabled ethernet drivers is needed at<br />this point. And we already know that much more hard work on fixing<br />wifi is needed.<br /><br />Despite this I'm generally pleased with the fq_codel results over<br />wireless I'm currently getting from today's build of cerowrt, and<br />certainly the BQL-enabled ethernet drivers I've worked with (ar71xx,<br />e1000) don't display this behavior, neither does soft rate limiting<br />using htb - instead achieving a steady state for the packet backlog,<br />accepting bursts, and otherwise being "nice".<br /><br />-- <br />Dave Täht<br />SKYPE: davetaht<br />http://ronsravings.blogspot.com/<br />_______________________________________________<br />Cerowrt-devel mailing list<br />Cerowrt-devel@lists.bufferbloat.net<br />https://lists.bufferbloat.net/listinfo/cerowrt-devel</p>
</div></font>