From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.taht.net (mail.taht.net [IPv6:2a01:7e00::f03c:91ff:feae:7028]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 115453B29E for ; Sat, 1 Apr 2017 00:05:44 -0400 (EDT) Received: from dair-2642.lan (unknown [IPv6:2601:646:8501:df5:d1ca:f017:d4c9:cbb0]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.taht.net (Postfix) with ESMTPSA id B8B7821425 for ; Sat, 1 Apr 2017 04:05:42 +0000 (UTC) To: bloat@lists.bufferbloat.net References: <99097E93-05AB-46F8-8545-E140C37ACAF3@pnsol.com> <1198438634.8472041.1490998044375@mail.yahoo.com> From: =?UTF-8?Q?Dave_T=c3=a4ht?= Message-ID: <48309bca-99bc-737e-7440-198f11d9fe01@taht.net> Date: Fri, 31 Mar 2017 21:05:40 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: <1198438634.8472041.1490998044375@mail.yahoo.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Subject: Re: [Bloat] I have a new record for bloat X-BeenThere: bloat@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: General list for discussing Bufferbloat List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Apr 2017 04:05:44 -0000 On 3/31/17 3:07 PM, Alex Burr wrote: > > > > > On Saturday, February 11, 2017 9:05 AM, Neil Davies wrote: > > >> The same mindset that created these sort of performance artefacts is also driving changes in DSL >> standards, so watch out for these sort of artefacts (again induced by things that you have no direct >> control over) starting to occur in “high speed” DSL systems (such as VDSL) when conditions are less > >> than perfect. > > Are you referring to G.998.4? That's supposed to introduce a max of 63ms delay. But it's been a while since I was involved in DSL, so maybe it's something new... It's not the encoding, it's the queuing. Unless they also adopt something like "bql" in their ring buffers in their firmware, and something like fq_codel slightly above that, under distant conditions or when rate limited by the provider, they new stuff will bloat up. > > Alex > _______________________________________________ > Bloat mailing list > Bloat@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/bloat >