From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by huchra.bufferbloat.net (Postfix) with ESMTPS id 6950A21F118 for ; Tue, 10 Dec 2013 00:04:56 -0800 (PST) Received: by uplift.swm.pp.se (Postfix, from userid 501) id CD4839C; Tue, 10 Dec 2013 09:04:53 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id BE5B59A; Tue, 10 Dec 2013 09:04:53 +0100 (CET) Date: Tue, 10 Dec 2013 09:04:53 +0100 (CET) From: Mikael Abrahamsson To: Neil Davies In-Reply-To: <1B54D30E-AB4D-4410-B1FB-CC93022B7C8F@pnsol.com> Message-ID: References: <26FB3C56-AF24-497C-943A-3FDAE7B88D08@isoc.org> <1B54D30E-AB4D-4410-B1FB-CC93022B7C8F@pnsol.com> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Cc: bloat Subject: [Bloat] ADSL2+ interleaving (Re: CFP: Workshop on Reducing Internet Latency) 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: Tue, 10 Dec 2013 08:04:56 -0000 On Tue, 10 Dec 2013, Neil Davies wrote: > We've seen this even when we've played with the settings through the > customer portal (I'm' in the UK - the provisioning portal allows many > such changes). > > Are you capturing any evidence of DSL modem state when this occurs? Well, we saw the problems mostly on medium-short spans, such as 1000-1500 meters. The packet loss wasn't as high as 20%, but it was consistant over time and showed up as errored seconds. I do not work there anymore, and this was 7 years ago. Interleaving spans bits over longer period of time, so if you're running fast mode and you get a 1ms "hit" on the link, the FEC (forward error correction) gets too many bits corrupted and gets overwhelmed. If one instead has 16ms interleaving, a lot fewer bits from one packet gets corrupted, and FEC can correct the errors. So your theory about line noise on specific frequencies is probably correct, you're not getting a big enough hit to trigger a re-train, but you're getting enough bit errors to cause post-FEC errors and thus packet loss. A re-train probably identifies the noise on those frequencies and uses them less. In our DSLAM we could see the frequency band profile via a show command, have you done this? -- Mikael Abrahamsson email: swmike@swm.pp.se