From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from plane.gmane.org (plane.gmane.org [80.91.229.3]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by huchra.bufferbloat.net (Postfix) with ESMTPS id 7C9F821F2B5 for ; Sat, 2 May 2015 04:45:24 -0700 (PDT) Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1YoVrA-0006Fw-R6 for bloat@lists.bufferbloat.net; Sat, 02 May 2015 13:45:16 +0200 Received: from host-92-11-217-230.as43234.net ([92.11.217.230]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 02 May 2015 13:45:16 +0200 Received: from alan.christopher.jenkins by host-92-11-217-230.as43234.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 02 May 2015 13:45:16 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: bloat@lists.bufferbloat.net From: Alan Jenkins Date: Sat, 02 May 2015 12:45:05 +0100 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: host-92-11-217-230.as43234.net User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 In-Reply-To: Subject: Re: [Bloat] Question about fq_codel vs modem buffers 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: Sat, 02 May 2015 11:45:55 -0000 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