From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-vb0-x236.google.com (mail-vb0-x236.google.com [IPv6:2607:f8b0:400c:c02::236]) (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 D1CB121F150 for ; Tue, 27 Aug 2013 06:31:40 -0700 (PDT) Received: by mail-vb0-f54.google.com with SMTP id q14so2946254vbe.41 for ; Tue, 27 Aug 2013 06:31:39 -0700 (PDT) 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=RosbQMVyIRnIQPqN+YbGuW8fQY7e5iFuqhMGobbHxCY=; b=BZ40HMwLrdjVcK422X/ww+62yon254X6VVi1wI5oRWXxdEvN9kkZPXxl5MFC8qQeui bsX3JMDDnL5mFvSPvLQ72PY/A4x9+Y9Xq4uJ+JOrJpSnSsPGJ7M7p87ij7ZYKzkJZIfe /xq6pHA1rL+0VSfCjWGj3ChxCYfsTN20ARYXLkkrDDcP2u4GHl/6NW56mMqwEgkSapLb 8Ohaz4V2L6WVxSMck9ReBeZBAA+o46Qx/LteKxHL63gKJYT9O54uleJ69SgC40TMZquI 82erByJ9qnBYhctyXw7t1BkCLtfanYO2ILiOtHyakzP632f+QghT/ZTqAeHzjcHr0yCL 6rqQ== MIME-Version: 1.0 X-Received: by 10.52.180.229 with SMTP id dr5mr16919448vdc.20.1377610299465; Tue, 27 Aug 2013 06:31:39 -0700 (PDT) Received: by 10.221.51.198 with HTTP; Tue, 27 Aug 2013 06:31:39 -0700 (PDT) In-Reply-To: References: Date: Tue, 27 Aug 2013 15:31:39 +0200 Message-ID: From: Naeem Khademi To: Dave Taht Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: bloat Subject: Re: [Bloat] how to fix modem buffer bloat? X-BeenThere: bloat@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list List-Id: General list for discussing Bufferbloat List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Aug 2013 13:31:41 -0000 I would like to hear a bit of more elaboration on why the use of fq_codel on wlanX interface is "premature". from what I have grasped so far, I can think of A) frame aggregation and TXOPs in 802.11n, B) anything on the downlink path that coexists with uplink traffic on 802.11g/n. any thoughts on other major issues? excluding .11n-specific issues, what else could be problematic for fq_codel for a 802.11g scenario with predominantly downlink traffic and minstrel RA? Regards, Naeem On Mon, Aug 26, 2013 at 9:28 PM, Dave Taht wrote: > The advantage of cerowrt is that it runs about 3-4 months ahead of openwr= t > on improvements to the bloat problem, and fixing bugs. > > The disadvantage is that it runs about 3-4 months ahead of openwrt on hav= ing > new bugs. > > Example: We just finished (with the aid of multiple parties ) finally fix= ing > a problem in HTB's atm DSL compensation that has existed for a year (and > probably several years before that), and I think the final set of fixes w= ill > land in Linux 3.10.10 or .11 soon. > > Right now it's very possible to merely layer two components of cero on to= p > of openwrt to get most of the benefit of the current work. (the aqm-scrip= ts > and gui, and if you are daring, a couple patches to codel and fq_codel) > > Sadly, I wouldn't recomend the current dev builds of cero for day-to-day = use > at this point, although I hope to get to a new stable release by the end = of > september. There's a ton of outstanding bugs left to fix. > > While openwrt runs fq_codel by default on all interfaces, it's mildly > premature to be doing so on the wifi front. Work is in progress. However = in > the general case, at the moment the principal use for fq_codel in a home > router is on the gateway to the internet - the fq_codel QoS system in > openwrt and dd-wrt works extremely well (with the exception of ipv6 nativ= e). > I believe the package in cerowrt is better in most respects (notably on > ipv6), but limited in others. Gargoyle is using a prior effort (improved = sfq > + an automatic rate measurement system called ACC). There are other optio= ns > like using small atom boxes, ipfire, and several commercial products.... > > The stable (feburary) release of cero is pretty usable, but lacks the > modernized aqm scripts, the htb fix, a bunch of ipv6 fixes, etc, etc. > > I wish I could give firm advice, but we're kind of in the middle of a ton= of > stuff right now, all I can do is encourage you to leap in, fix things for > yourself, and help out where you can. > > > > On Mon, Aug 26, 2013 at 11:53 AM, Collin Anderson > wrote: >> >> Hi All, >> >> > Any recommendations for solving the bufferbloat on my Comcast SMC cabl= e >> > modem? >> >> Looking at it more, a workaround is probably all I can hope for at >> this point. I first started keeping a ping session open back in 2008 >> to debug the internet, and I see bufferbloat almost every day at home >> and at work. Anything to avoid the symptoms sounds great. >> >> I want something reliable and have minimal configuration. I'm thinking >> about buying a WNDR3800 and installing CeroWRT, or is there better >> recommended hardware? >> >> Also, isn't fq_codel "on by default" [1] in OpenWRT? If so, what's the >> advantage of CeroWRT? >> >> Thanks, >> Collin >> >> [1] http://www.ietf.org/proceedings/87/slides/slides-87-aqm-6.pdf >> _______________________________________________ >> Bloat mailing list >> Bloat@lists.bufferbloat.net >> https://lists.bufferbloat.net/listinfo/bloat > > > > > -- > Dave T=E4ht > > Fixing bufferbloat with cerowrt: > http://www.teklibre.com/cerowrt/subscribe.html > > _______________________________________________ > Bloat mailing list > Bloat@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/bloat >