From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp171.iad.emailsrvr.com (smtp171.iad.emailsrvr.com [207.97.245.171]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by huchra.bufferbloat.net (Postfix) with ESMTPS id 897212013A1; Tue, 19 Jun 2012 20:01:45 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp37.relay.iad1a.emailsrvr.com (SMTP Server) with ESMTP id 3926A3B07AD; Tue, 19 Jun 2012 23:01:44 -0400 (EDT) X-Virus-Scanned: OK Received: from legacy21.wa-web.iad1a (legacy21.wa-web.iad1a.rsapps.net [192.168.2.207]) by smtp37.relay.iad1a.emailsrvr.com (SMTP Server) with ESMTP id 0FEEF3B07A2; Tue, 19 Jun 2012 23:01:44 -0400 (EDT) Received: from reed.com (localhost.localdomain [127.0.0.1]) by legacy21.wa-web.iad1a (Postfix) with ESMTP id F16DB1CE8066; Tue, 19 Jun 2012 23:01:43 -0400 (EDT) Received: by apps.rackspace.com (Authenticated sender: dpreed@reed.com, from: dpreed@reed.com) with HTTP; Tue, 19 Jun 2012 23:01:43 -0400 (EDT) Date: Tue, 19 Jun 2012 23:01:43 -0400 (EDT) From: dpreed@reed.com To: "Dave Taht" MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_20120619230143000000_32070" Importance: Normal X-Priority: 3 (Normal) X-Type: html In-Reply-To: References: Message-ID: <1340161303.987626147@apps.rackspace.com> X-Mailer: webmail7.0 X-Mailman-Approved-At: Wed, 20 Jun 2012 06:17:07 -0700 Cc: codel@lists.bufferbloat.net, cerowrt-devel@lists.bufferbloat.net Subject: Re: [Codel] [Cerowrt-devel] codel "oversteer" X-BeenThere: codel@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list List-Id: CoDel AQM discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jun 2012 03:01:45 -0000 ------=_20120619230143000000_32070 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =0AOne further thought - the time constants may well be adjusted so that th= ere is what we in radio call an impedance mismatch (I mean it literally, no= t metaphorically) such that there is an SWR much greater than 1. In an ant= enna feedline this results in oscillations of power that travel back and fo= rth between transmitter and antenna, resulting in pulsating power delivered= to the antenna.=0A =0ADo you know the time constants of the TCP source con= gestion control algorithm (frequency of the "sawtooth" that arrives when th= ere is a short queue) and the codel control loop? If they are really diffe= rent, you get a significant "beat frequency" between the two oscillators. = This would directly create the observed phenomenon.=0A =0AI think you can = probably tune one natural frequency or the other until there is an impedanc= e match, and then the codel damping should work.=0A =0AMaybe this could be= simulated in a simple simulator that models the situation to see if this i= s "normal" given the parameters, or whether it is a logic bug in one implem= entation or the other.=0A =0A-----Original Message-----=0AFrom: "Dave Taht"= =0ASent: Tuesday, June 19, 2012 9:32pm=0ATo: codel@li= sts.bufferbloat.net, cerowrt-devel@lists.bufferbloat.net=0ASubject: [Cerowr= t-devel] codel "oversteer"=0A=0A=0A=0AI've been forming a theory regarding = codel behavior in some=0Apathological conditions. For the sake of developin= g the theory I'm=0Agoing to return to the original car analogy published he= re, and add a=0Anew one - "oversteer".=0A=0ABriefly:=0A=0AIf the underlying= interface device driver is overbuffered, when the=0Apacket backlog finally= makes it into the qdisc layer, that bursts up=0Arapidly and codel rapidly = ramps up it's drop strategy, which corrects=0Athe problem, but we are back = in a state where we are, as in the case=0Aof an auto on ice, or a very loos= e connection to the steering wheel,=0A"oversteering" because codel is actua= lly not measuring the entire=0Atime-width of the queue and unable to contro= l it well, even if it=0Acould.=0A=0AWhat I observe on wireless now with fq_= codel under heavy load is=0Aoscillation in the qdisc layer between 0 length= queue and 70 or more=0Apackets backlogged, a burst of drops when that happ= ens, and far more=0Adrops than ecn marks that I expected (with the new (ar= bitrary) drop=0Aecn packets if > 2 * target idea I was fiddling with illust= rating the=0Apoint better, now). It's difficult to gain further direct insi= ght=0Awithout time and packet traces, and maybe exporting more data to=0Aus= erspace, but this kind of explains a report I got privately on x86=0A(no ec= n drop enabled), and the behavior of fq_codel on wireless on the=0Apresent = version of cerowrt.=0A=0A(I could always have inserted a bug, too, if it wa= sn't for the private=0Areport and having to get on a plane shortly I wouldn= 't be posting this=0Anow)=0A=0AFurther testing ideas (others!) could try wo= uld be:=0A=0AIncrease BQL's setting to over-large values on a BQL enabled i= nterface=0Aand see what happens=0ATest with an overbuffered ethernet interf= ace in the first place=0AImprove the ns3 model to have an emulated network = interface with=0Auser-settable buffering=0A=0AAssuming I'm right and others= can reproduce this, this implies that=0Afocusing much harder on BQL and ov= erbuffering related issues on the=0Adozens? hundreds? of non-BQL enabled et= hernet drivers is needed at=0Athis point. And we already know that much mor= e hard work on fixing=0Awifi is needed.=0A=0ADespite this I'm generally ple= ased with the fq_codel results over=0Awireless I'm currently getting from t= oday's build of cerowrt, and=0Acertainly the BQL-enabled ethernet drivers I= 've worked with (ar71xx,=0Ae1000) don't display this behavior, neither does= soft rate limiting=0Ausing htb - instead achieving a steady state for the = packet backlog,=0Aaccepting bursts, and otherwise being "nice".=0A=0A-- =0A= Dave T=C3=A4ht=0ASKYPE: davetaht=0Ahttp://ronsravings.blogspot.com/=0A_____= __________________________________________=0ACerowrt-devel mailing list=0AC= erowrt-devel@lists.bufferbloat.net=0Ahttps://lists.bufferbloat.net/listinfo= /cerowrt-devel ------=_20120619230143000000_32070 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

One furthe= r thought - the time constants may well be adjusted so that there is what w= e in radio call an impedance mismatch (I mean it literally, not metaphorica= lly) such that there is an SWR much greater than 1.  In an antenna fee= dline this results in oscillations of power that travel back and forth betw= een transmitter and antenna, resulting in pulsating power delivered to the = antenna.

=0A

 

=0A

Do you know the time constants of the TCP source congest= ion control algorithm (frequency of the "sawtooth" that arrives when there = is a short queue) and the codel control loop?  If they are really diff= erent, you get a significant "beat frequency" between the two oscillators.&= nbsp;  This would directly create the observed phenomenon.

=0A

 

=0A

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.

= =0A

 

=0A

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.

=0A

 

=0A

-----Original Me= ssage-----
From: "Dave Taht" <dave.taht@gmail.com>
Sent: Tu= esday, June 19, 2012 9:32pm
To: codel@lists.bufferbloat.net, cerowrt-d= evel@lists.bufferbloat.net
Subject: [Cerowrt-devel] codel "oversteer"<= br />

=0A
=0A

I've been forming a theory regarding codel behavior in some
pathological conditions. For the sake of developing the theory I'm
g= oing to return to the original car analogy published here, and add a
n= ew one - "oversteer".

Briefly:

If the underlying inte= rface device driver is overbuffered, when the
packet backlog finally m= akes 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 b= ack in a state where we are, as in the case
of an auto on ice, or a ve= ry loose connection to the steering wheel,
"oversteering" because code= l is actually not measuring the entire
time-width of the queue and una= ble to control it well, even if it
could.

What I observe on= wireless now with fq_codel under heavy load is
oscillation in the qdi= sc layer between 0 length queue and 70 or more
packets backlogged, a b= urst of drops when that happens, and far more
drops than ecn marks tha= t I expected (with the new (arbitrary) drop
ecn packets if > 2 * t= arget idea I was fiddling with illustrating the
point better, now). It= 's difficult to gain further direct insight
without time and packet tr= aces, and maybe exporting more data to
userspace, but this kind of exp= lains a report I got privately on x86
(no ecn drop enabled), and the b= ehavior 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 priv= ate
report and having to get on a plane shortly I wouldn't be posting = this
now)

Further testing ideas (others!) could try would b= e:

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 emulate= d network interface with
user-settable buffering

Assuming I= 'm right and others can reproduce this, this implies that
focusing muc= h harder on BQL and overbuffering related issues on the
dozens? hundre= ds? of non-BQL enabled ethernet drivers is needed at
this point. And w= e already know that much more hard work on fixing
wifi is needed.

Despite this I'm generally pleased with the fq_codel results overwireless I'm currently getting from today's build of cerowrt, and
c= ertainly the BQL-enabled ethernet drivers I've worked with (ar71xx,
e1= 000) don't display this behavior, neither does soft rate limiting
usin= g htb - instead achieving a steady state for the packet backlog,
accep= ting bursts, and otherwise being "nice".

--
Dave T=C3=A4ht=
SKYPE: davetaht
http://ronsravings.blogspot.com/
__________= _____________________________________
Cerowrt-devel mailing list
= Cerowrt-devel@lists.bufferbloat.net
https://lists.bufferbloat.net/list= info/cerowrt-devel

=0A
 ------=_20120619230143000000_32070--