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 <[email protected]> wrote: > The advantage of cerowrt is that it runs about 3-4 months ahead of openwrt > on improvements to the bloat problem, and fixing bugs. > > The disadvantage is that it runs about 3-4 months ahead of openwrt on having > new bugs. > > Example: We just finished (with the aid of multiple parties ) finally fixing > 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 will > land in Linux 3.10.10 or .11 soon. > > Right now it's very possible to merely layer two components of cero on top > of openwrt to get most of the benefit of the current work. (the aqm-scripts > 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 native). > 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 options > 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 <[email protected]> > wrote: >> >> Hi All, >> >> > Any recommendations for solving the bufferbloat on my Comcast SMC cable >> > 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 >> [email protected] >> https://lists.bufferbloat.net/listinfo/bloat > > > > > -- > Dave Täht > > Fixing bufferbloat with cerowrt: > http://www.teklibre.com/cerowrt/subscribe.html > > _______________________________________________ > Bloat mailing list > [email protected] > https://lists.bufferbloat.net/listinfo/bloat > _______________________________________________ Bloat mailing list [email protected] https://lists.bufferbloat.net/listinfo/bloat
