General list for discussing Bufferbloat
 help / color / mirror / Atom feed
From: Alan Jenkins <alan.christopher.jenkins@gmail.com>
To: bloat@lists.bufferbloat.net
Subject: Re: [Bloat] Question about fq_codel vs modem buffers
Date: Sat, 02 May 2015 12:45:05 +0100	[thread overview]
Message-ID: <mi2dc1$q18$1@ger.gmane.org> (raw)
In-Reply-To: <A12346C7-149F-46FA-A698-69FA5AEF56A6@gmail.com>

On 02/05/15 03:49, Rich Brown wrote:
> I posted a message about using SQM & OpenWrt on Tom's Hardware, and got a response from someone who's somewhat knowledgeable. I'm not sure of the proper response, so I wanted to ask here first. Here's the question that has me stumped.
>
> http://www.tomshardware.com/answers/id-2615979/high-latency-person-internet.html#15786081
>
> My thoughts:
>
> I know fq_codel takes control of the bottleneck by being set to a couple percent below the fastest link speeds observed in each direction.
>
> The author of the rebuttal says that the (DSL or Cable) modem buffers will fill up if the "upload drops from 3 to 2mbps". I can think of two ways this can happen:
> 	- Actual link bit rate drops
> 	- Congestion/oversubscription in the head end causes effective data rate to drop
>
> But I don't know enough about the physical characteristics of cable/dsl links to understand how they actually work, nor how fq_codel can (or can't) accommodate degradation.
>
> Could someone help me shape a response? Thanks.
>
> Rich

Basically don't worry too much about this.  The criticism was correct. 
Your critic is not spreading damagingly incorrect technical information 
and is on-cause AFAICT.  I don't think there's anything left to add to 
that thread now, just accept the criticism (post an agreement if you 
like, or not).

You have to "throttle" to under the link speed in openwrt.  If the link 
speed drops below that, your bloated modem will become the slowest link 
again ("bottleneck" - where it narrows and flows slowest, get it?), and 
a queue will build there.

OP has a variable (rural) link so it sucks.  But if you're noticing 
1000-4000ms bufferbloat that sucks more in many cases, if you can avoid 
it by throttling below your slowest usable link speed, you'll likely 
benefit from that.

Particularly if you're above 5Mbps anyway like this guy; allegedly 
that's the cutoff where throughput stops mattering so much for web browsing.

https://www.igvita.com/2012/07/19/latency-the-new-web-performance-bottleneck/
(un-cited, graph, sorry, I wish I knew where it came from).

As he says, the correct technical solution is to fix the modem to run 
fq_codel.  Then fq_codel will limit the queue that builds up at the 
bottleneck.  It avoids the need for throttling and will work with 
variable line rates.  But the modems aren't open-source, so we're 
demonstrating the fix with external routers.  Eventually ISPs will wise 
up and procure modems with fixes.  Like the PIE queuing discipline which 
is being standardized for next-generation cable modems.  (It's a start 
anyway, even if it's not as good as fq_codel).

Alan


  parent reply	other threads:[~2015-05-02 11:45 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-05-02  2:49 Rich Brown
2015-05-02 11:35 ` Sebastian Moeller
2015-05-02 11:42 ` Jan Ceuleers
2015-05-02 11:45 ` Alan Jenkins [this message]
2015-05-02 16:09   ` 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='mi2dc1$q18$1@ger.gmane.org' \
    --to=alan.christopher.jenkins@gmail.com \
    --cc=bloat@lists.bufferbloat.net \
    /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