From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ia0-f180.google.com (mail-ia0-f180.google.com [209.85.210.180]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority" (verified OK)) by huchra.bufferbloat.net (Postfix) with ESMTPS id F303A21F107 for ; Fri, 21 Dec 2012 10:57:43 -0800 (PST) Received: by mail-ia0-f180.google.com with SMTP id t4so4162718iag.39 for ; Fri, 21 Dec 2012 10:57:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=H/pnrDDhZ/OHKPdJ4cijDqY72mS6owD+JIm0SU+bYsY=; b=WQdlgMMS4h8Kg4UnqSNo5GUlINzMjjCRPsMMzuSpuzZHCMyppA7Nyf6bRcPDacY2Q8 XNI+qXesobZEVKzebZv+8kq9X6k6DkFNBuNHmwqtFyjVqSUA1TcZZpxQxoK9vvx84qPk fW+1hAIbdUXC77SzR4/aXRoSKqD54bsj/YKJo14xqzXE6cc2kOaGQEsGLoyevb0kl+tz 704d8nrhJqrNPUhACptHN5/DuiU5Jn8HdbOO+yfTdrj1olW6o6Id/BXtJ19hFb6q2Uoy IVIvcN+vJbGMobA7ITHKUlAEmXnnWevijKAb2hS9vk0C+r8UQSLtALgrha39LIhXxWHG lJsA== MIME-Version: 1.0 Received: by 10.50.157.162 with SMTP id wn2mr14215598igb.27.1356116263373; Fri, 21 Dec 2012 10:57:43 -0800 (PST) Received: by 10.64.135.39 with HTTP; Fri, 21 Dec 2012 10:57:43 -0800 (PST) In-Reply-To: References: <2lps03vacpqmtehlf4gnq634.1356112034562@email.android.com> Date: Fri, 21 Dec 2012 19:57:43 +0100 Message-ID: From: Dave Taht To: Jim Gettys Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "codel@lists.bufferbloat.net" Subject: Re: [Codel] R: Making tests on Tp-link router powered by Openwrt svn 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: Fri, 21 Dec 2012 18:57:44 -0000 On Fri, Dec 21, 2012 at 7:30 PM, Jim Gettys wrote: > > > > On Fri, Dec 21, 2012 at 12:51 PM, Alessandro Bolletta > wrote: >> >> Hi everybody, >> Thanks so much for your useful help! I solved my problem by reproducing >> bottleneck through HTB queues. >> I tried some bandwidth rates and i saw that target must be increased if >> the available bandwidth is <4mbps. 13ms is a good compromise for that >> situation. >> Also, i removed the switch from my testbed. >> Codel works amazingly well, congratulations for the job that has been >> done! >> I'll try to make more tests to ensure that it will be suitable for our >> needs; we are building a new wireless mesh network in Italy based on a >> totally new architecture and Codel could be a great improvement for queu= e >> management on the nodes. >> >> Thanks again for your courtesy! >> Alessandro Bolletta > > > Kathy, > > So in this case, there is another packet of buffering *under* the codel > queue in the HTB line discipline (which buffers one packet), plus whateve= r > additional buffering of there may be in the device driver (where the mile= age > varies). Which exits at line rate, so it's not a huge issue timewise, particularly in an age where cable modems are specced to run at gigE. > So codel isn't actually dropping the head of the queue, but the second (o= r > further) packet back, in effect. So the control law computation won't be > quite right. > - Jim It certainly is feasible to produce a version of fq_codel that is like tbf or htb internally. Eric figured it would be a couple dozen lines of code... Actually it could be simpler in terms of interacting with the linux scheduler than those alternatives as we're doing timestamping anyway, so with an explicit bandwidth limit it's straightforward to predict when the next packet can be delivered at what re-scheduled time.... It would save an unmanaged packet outstanding, too. Well, hmm, that would have to get looked at by the estimator... Use cases: 1) ISPs artificially rate limit lines regardless 2) So do virtual service providers 3) our current need to reduce bandwidth to below the crappy device next in line.. The last problem is so pervasive that I have a whole bunch of complex htb scripts to do it right. It would be easier to have a rate limited fq_codel (well, one that also does prioritization like pfifo_fast) and less cpu intensive to move all that logic out of the combination of fq_codel + htb and into one qdisc... just a thought... --=20 Dave T=E4ht Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscribe.= html