From: Naeem Khademi <naeem.khademi@gmail.com>
To: Dave Taht <dave.taht@gmail.com>
Cc: bloat <bloat@lists.bufferbloat.net>
Subject: Re: [Bloat] how to fix modem buffer bloat?
Date: Tue, 27 Aug 2013 15:31:39 +0200 [thread overview]
Message-ID: <CAEjQQ5VA3vKeNqDsD8kW6q0EY3wKsab+Q+CbKCmmutY9GOOkhQ@mail.gmail.com> (raw)
In-Reply-To: <CAA93jw6HDs_PQCifR2UzYockyHX41QRjF5=botkZhKtbKdbpWA@mail.gmail.com>
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 <dave.taht@gmail.com> 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 <cmawebsite@gmail.com>
> 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
>> Bloat@lists.bufferbloat.net
>> https://lists.bufferbloat.net/listinfo/bloat
>
>
>
>
> --
> Dave Täht
>
> Fixing bufferbloat with cerowrt:
> http://www.teklibre.com/cerowrt/subscribe.html
>
> _______________________________________________
> Bloat mailing list
> Bloat@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/bloat
>
next prev parent reply other threads:[~2013-08-27 13:31 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-08-26 1:03 Collin Anderson
2013-08-26 18:53 ` Collin Anderson
2013-08-26 19:01 ` Kenyon Ralph
2013-08-26 19:28 ` Dave Taht
2013-08-26 20:18 ` Collin Anderson
2013-08-27 13:31 ` Naeem Khademi [this message]
2013-08-27 18:11 ` Dave Taht
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://lists.bufferbloat.net/postorius/lists/bloat.lists.bufferbloat.net/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAEjQQ5VA3vKeNqDsD8kW6q0EY3wKsab+Q+CbKCmmutY9GOOkhQ@mail.gmail.com \
--to=naeem.khademi@gmail.com \
--cc=bloat@lists.bufferbloat.net \
--cc=dave.taht@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox