From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "mout.gmx.net", Issuer "TeleSec ServerPass DE-1" (verified OK)) by huchra.bufferbloat.net (Postfix) with ESMTPS id 188A521F2B4 for ; Sat, 2 May 2015 04:35:24 -0700 (PDT) Received: from hms-beagle-5.home.lan ([217.247.216.138]) by mail.gmx.com (mrgmx001) with ESMTPSA (Nemesis) id 0LlUZz-1ZNI5d0kBb-00bJVm; Sat, 02 May 2015 13:35:22 +0200 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Sebastian Moeller In-Reply-To: Date: Sat, 2 May 2015 13:35:28 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <01D09A76-21EC-449F-B208-D5D44004D4C8@gmx.de> References: To: Rich Brown X-Mailer: Apple Mail (2.1878.6) X-Provags-ID: V03:K0:KcBci6C0Rk84CQkNDmf72H8sHg6W8Gk0Nk/1JsQJYf5stN40d4b qVcxqq3Vig0pxliYS++4nyptcfs74zbiur8jaNY+fJa4SreBQJ7Y9ubWr6DHj9wb3ZTFO6E Y6ZkspmLiiW980tKQkz5Fp7sD2/rmAz0o21XKbKpZxc2dwqAP31bl7FkC/rRfATtTBFcJQB IlcLt6pMLlPoVWoE7vvcg== X-UI-Out-Filterresults: notjunk:1; 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 11:35:53 -0000 Hi Rich, On May 2, 2015, at 04: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. >=20 > = http://www.tomshardware.com/answers/id-2615979/high-latency-person-interne= t.html#15786081 >=20 > My thoughts: >=20 > 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. >=20 > 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 Yes that can happen, e.g. in oversubscribed cable systems; = currently sqm-scripts and or qos-scripts can NOT deal with this, = gargoyle arguable can with its active controller (which is ping based = and will allow to control reasonably slow bandwidth fluctuations on the = order of seconds). This should be quite uncommon for DSL-links (caveat: = seamless rate adaptation would make this les rare, but I yet have to see = proof f SRA deployment in the field ;) ). > - Congestion/oversubscription in the head end causes effective = data rate to drop This should not fill up the modem=92s buffer, but the = DSLAM=92s/MMTS's; but no matter where as long as the buffers are badly = controlled buffer bloat will rear its ugly head again ;) In my opinion, = the poster is right in theory the shaper needs to be set at <=3D the = effective max transmit rate. Now oversubscription of the DSLAM=92s/CMTS=92= s uplink is somewhat tricky to handle as it it will result in wildly = fluctuating rates that are hard to track from the CPE side, also I think = there is no guarantee that each CPE gets the same % of the uplink, so = shaping in the CPE to reduce buffer bloat might result in no latency = under load improvement while still sacrificing bandwidth. One really = hopes that the head-end manufacturers get fq_codel into those devices = (and potentially not in a flow fair, but in a prefix fair way so that = all CPEs/customers are treated equally). >=20 > 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. So currently we relay on HTB (or in the near future cake) to = shape the rate so that we make sure the bottleneck link stays under our = control. Neither HTB nor cake have enough insight in the upstream = network topology/traffic to adjust their shaper to counter degradation = of effective bandwidth. I really should look into gargoyle=92s = controller to figure out whether we can borrow this easily and include = this as an add-on to sqm-scripts (it should not be rocket science, just = configure a target-IP for continuous ping probes and react to latency = increases above a threshold with rate reductions; the devil will be in = the details, like when to open up the bandwidth again, and how much to = actually change the throttle, but these should be open to empiric = research). Best Regards Sebastian >=20 > Could someone help me shape a response? Thanks. >=20 > Rich >=20 >=20 > _______________________________________________ > Bloat mailing list > Bloat@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/bloat