From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ob0-x232.google.com (mail-ob0-x232.google.com [IPv6:2607:f8b0:4003:c01::232]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by huchra.bufferbloat.net (Postfix) with ESMTPS id 98D4D21F277 for ; Sat, 2 May 2015 09:09:59 -0700 (PDT) Received: by obbkp3 with SMTP id kp3so27357855obb.3 for ; Sat, 02 May 2015 09:09:49 -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=L3njFChoKmaVEp4A3epdMQWnUWcAGYNJwApDI7LSylQ=; b=xY7JHXjOYMynzLfQ/CtuI7FsLtl2cNpqkIMWLn4zaTrWQvb6/tVMnyVaT5fKbeAnBI BFjHjYqETphL1NFRlBGxd25tiEvPuomgCFQEWEx34K6MlS2bZq7MpP5MtrheYWk9tFxb iLLoKl0dx8P65oSzkO00dPuUNXMDJ0NsODojG/3iPiYEY+amw3rNHnayVrSdTKDrIqQw McnMar0ZldMGxAb2e22/gTh2CeKFVqVYtA85a9/zIUL06QsQsN+v9YUALd/A+Ma0oVME tlnmTuwyHpE7VCBRUzHJnS5agOaTPBCcJH0PCcJLhLX4t9bq0oGivgiY5qexrjUqaVNH YGkA== MIME-Version: 1.0 X-Received: by 10.202.227.130 with SMTP id a124mr11543957oih.59.1430582989844; Sat, 02 May 2015 09:09:49 -0700 (PDT) Received: by 10.202.71.139 with HTTP; Sat, 2 May 2015 09:09:49 -0700 (PDT) In-Reply-To: References: Date: Sat, 2 May 2015 09:09:49 -0700 Message-ID: From: Dave Taht To: Alan Jenkins Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: bloat 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 16:10:34 -0000 On Sat, May 2, 2015 at 4:45 AM, Alan Jenkins wrote: > 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-inter= net.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. in software rate limiting *HTB* takes control of the bottleneck. fq_codel then manages the queue length and packet scheduling. IF the fq_codel algorithm is instead located close to the mac layer of the hardware and can "see" the latency, then it can respond to changes in line rate. This is how BQL works. It works fairly poorly (today) on wifi as there are too many buffers between fq_codel and the wifi device (and a few other reasons) >> The author of the rebuttal says that the (DSL or Cable) modem buffers wi= ll >> fill up if the "upload drops from 3 to 2mbps". I can think of two ways t= his >> can happen: >> - Actual link bit rate drops >> - Congestion/oversubscription in the head end causes effective >> data rate to drop I tried to answer on the post, couldn't get it to take my answer. I wrote: @kewix25: You are correct: A) if your line rate is not fixed, then software shaping htb + fq_codel to a rate below that observed on one test will misbehave on the times that the line rate drops below that. It is generally unknown to what extent ISP line rates vary in this way, although line quality and contention ARE two figures that most ISPs monitor closely. In all my testing I have only found one cable plant (a large apartment building) that regularly showed major variance in the actual line rate achieved. B) Bufferbloat.net's push has always been for the ISPs and CPE makers to fix their gear in either hardware or software. If in software: It would help that - after getting a sqm-scripts install that worked - for users (and their ISPs!) be monitoring the line with smokeping, to see the cases where the line rate might drop and latencies skyrocket. Other ongoing measurements are possible (see gargoyle-router project for one implementation) - but the right answer has always been to get the hardware right. C) The promise in latency sensing AQM algorithms like pie and codel is indeed that they can dynamically adjust to changes of rate... when the algorithms are close enough to the hardware to measure it accurately. Next up for bufferbloat.net's researchers is trying to tackle wifi, which is far, far far more dynamic than dsl and cable links. There is some discussion of these questions on the bufferbloat.net bloat li= st. >> 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. Yo= ur > 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 thre= ad > 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 i= t > 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-bottlen= eck/ > (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 variabl= e > line rates. But the modems aren't open-source, so we're demonstrating th= e > fix with external routers. Eventually ISPs will wise up and procure mode= ms > 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 > > > _______________________________________________ > Bloat mailing list > Bloat@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/bloat --=20 Dave T=C3=A4ht Open Networking needs **Open Source Hardware** https://plus.google.com/u/0/+EricRaymond/posts/JqxCe2pFr67