From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mailrelay106.isp.belgacom.be (mailrelay106.isp.belgacom.be [195.238.20.133]) by huchra.bufferbloat.net (Postfix) with ESMTP id 79E3C21F307 for ; Sat, 2 May 2015 04:42:39 -0700 (PDT) X-Belgacom-Dynamic: yes X-Cloudmark-SP-Filtered: true X-Cloudmark-SP-Result: v=1.1 cv=Xz9Uco7AEzg9ElRFdtKQLJViOsXK4SGQVO9ewqrYxis= c=1 sm=2 a=tJe01QhAHdwA:10 a=N659UExz7-8A:10 a=-EWmk5QWduOVsPdqW0cA:9 a=pILNOxqGKmIA:10 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A2BfBgCPt0RV/zaA9FFcgwzMEYJdAoFPTQEBAQEBAYELhCEBAQRWBhwRCwsNCRYPCQMCAQIBERYeEwgBARiHegEYAbRziygKGYEKhEgBAQgCIIs5hQwWhBcBBJxfh0eFAIlXI4FlghE8gnYBAQE Received: from 54.128-244-81.adsl-dyn.isp.belgacom.be (HELO zotac.xperim.be) ([81.244.128.54]) by relay.skynet.be with ESMTP; 02 May 2015 13:42:37 +0200 Received: from [192.168.1.172] (mordor.xperim.be [192.168.1.172]) by zotac.xperim.be (8.14.4/8.14.4/Debian-2ubuntu2.1) with ESMTP id t42BgOOH032269 for ; Sat, 2 May 2015 13:42:24 +0200 Message-ID: <5544B820.6060503@gmail.com> Date: Sat, 02 May 2015 13:42:24 +0200 From: Jan Ceuleers User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: bloat@lists.bufferbloat.net References: In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit 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:43:09 -0000 On 02/05/15 04:49, Rich Brown wrote: > 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. I know a little about the DSL PHY behaviour. It is possible for line conditions to degrade, forcing the modems (i.e. the one in the DSLAM and the one in the CPE) to retrain. It is also possible that the newly-negotiated line rate is lower than the previous-one, so the end user would indeed see a reduction in the available bandwidth. However, DSL operators (the good-ones anyway) measure, log and manage the headroom between signal and noise on a per-line basis, so as to avoid this kind of instability. This is the case particularly for operators who also provide video services over DSL because retrains (which take quite a few seconds) kill the user experience. Take my line for example. I don't exactly know the length of my line to the DSLAM but it must be at least 1200m. Up until a few months ago I had 25.5Mbit/s down and 2Mbit/s up using VDSL2 without vectoring. But I know that my service provider, being in stiff competition with cable, has been silently upping the bandwidth of people's lines by first gathering stats on each individual line for a few months, and then, using a feature called dynamic line management that allows them to model the expected impact of increasing the rate of one line on the noise (crosstalk) experienced by the other lines in the same cable bundle, determine how far they can stretch each line. I now have 30M down and 2M up, still without vectoring, and with a training margin as reported by the modem of 9.6dB. (Before the speed upgrade I vaguely remember it being something like 14dB). So anyway: retrains are supposed to be very exceptional and indicative of something being wrong. By the way: another way for DSL operators to improve stability is to use interleaving. Specifically: interleaving helps to improve stability in the face of impulse noise at the expense of increased latency (which is why I mention it here). Jan