From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from eu1sys200aog103.obsmtp.com (eu1sys200aog103.obsmtp.com [207.126.144.115]) (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 B16C821F17D for ; Tue, 10 Dec 2013 00:07:40 -0800 (PST) Received: from mail.la.pnsol.com ([89.145.213.110]) (using TLSv1) by eu1sys200aob103.postini.com ([207.126.147.11]) with SMTP ID DSNKUqbLysW+ch9dsoAZoLei8RyAAUzZID+c@postini.com; Tue, 10 Dec 2013 08:07:40 UTC Received: from ba6-office.pnsol.com ([172.20.5.199]) by mail.la.pnsol.com with esmtp (Exim 4.76) (envelope-from ) id 1VqILy-0008Bd-0t; Tue, 10 Dec 2013 08:07:38 +0000 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Neil Davies In-Reply-To: Date: Tue, 10 Dec 2013 08:07:37 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <53680E91-D6BA-4F1A-893C-A08A40E5224E@pnsol.com> References: <26FB3C56-AF24-497C-943A-3FDAE7B88D08@isoc.org> <1B54D30E-AB4D-4410-B1FB-CC93022B7C8F@pnsol.com> To: Mikael Abrahamsson X-Mailer: Apple Mail (2.1510) Cc: bloat Subject: Re: [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:07:41 -0000 Don't have direct access to the DSLAM, but do have access to that = information in the modem - and yes and there appears to be a large = change in certain frequency buckets. The loss rates appear to vary with the offered load - i.e the "loss" = only occurs if there was real packet data in that frequency band On 10 Dec 2013, at 08:04, Mikael Abrahamsson wrote: > On Tue, 10 Dec 2013, Neil Davies wrote: >=20 >> 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). >>=20 >> Are you capturing any evidence of DSL modem state when this occurs? >=20 > 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. >=20 > 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. >=20 > 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. >=20 > In our DSLAM we could see the frequency band profile via a show = command, have you done this? >=20 > --=20 > Mikael Abrahamsson email: swmike@swm.pp.se