From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) (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 903C821F629 for ; Sat, 6 Jun 2015 11:14:12 -0700 (PDT) Received: from hms-beagle-6.home.lan ([217.237.71.188]) by mail.gmx.com (mrgmx003) with ESMTPSA (Nemesis) id 0M3AWN-1ZJO3b377H-00st2Q; Sat, 06 Jun 2015 20:14:08 +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: <557315CC.1060405@darbyshire-bryant.me.uk> Date: Sat, 6 Jun 2015 20:14:06 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <439DCDC5-13C9-4B8E-89A8-90977F90258A@gmx.de> References: <5572F7E0.3060602@darbyshire-bryant.me.uk> <0A0D06AB-CC83-4D99-80C6-8E7822C8707C@gmx.de> <557315CC.1060405@darbyshire-bryant.me.uk> To: Kevin Darbyshire-Bryant X-Mailer: Apple Mail (2.1878.6) X-Provags-ID: V03:K0:EIFHDTjr9nSRd2WlzoX+iyGVjqPlgniHlUhUCkL5dexPUKarUHh TlvYH4EdHMIOLT1AJ9VaAPO1o/q19DKUfF5zqxv6Hi5MzWhRguWlByqKaFET+GA5rFfHQm1 FjjLoBpY4mgYO7BEb1AUp/a9X3uKElV8agPNVtiWmxcyuMKDcA3I+lAppF/imFP+zKy48YZ zQLUUe43S73zjV7VfEHVw== X-UI-Out-Filterresults: notjunk:1; Cc: bloat@lists.bufferbloat.net Subject: Re: [Bloat] ADSL, ATM drivers, bloat, education & confusion 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, 06 Jun 2015 18:14:41 -0000 Hi Kevin, On Jun 6, 2015, at 17:46 , Kevin Darbyshire-Bryant = wrote: >=20 >=20 > On 06/06/15 15:29, Sebastian Moeller wrote: >> 1) ATM interface 'backpressure' - is this Byte Queue Limits? = (ifxmips_atm) >> Is there actual backpreassure from your ATM diver at all? As rar = as I know france=92s free had their boxes ATM driver modified to keep = buffering low, and I believe David Woodhouse dd some work on another = driver/the generic ATM layer, but I am not sure that any ATM driver = actually defaults to sane buffering and sane back pressure. > That was my sort of point. On 'planet Kevin' (don't go there) the ATM = driver would *know* the link is busy, or how many bytes it still had to = shove over it and could offer some clue back up the stack to not bloat. = I thought that's what BQL was supposed to do. Or another way of = viewing: If ethernet interfaces ideally implement BQL why shouldn't = ATM? Ah, I fully agree that is how I would like it to be as well; = unfortunately that is not sufficient to make it happen though :( >=20 >>=20 >>=20 >> How this is supposed to work? In an ideal work the CPE and the = DSLAM would not over-buffer and www would not have to dedicate grey = matter to work around their sort-commings ;) But as far as I can tell = DSL sync rates for many lines are stable over weeks to months, so = setting the shaper rarely is sufficient. Like when you notice that = latency under load got worse=85 > Well again on 'planet Kevin' the CPE is OpenWrt. =20 A planet I like to live on from what I learned about it. > Apparenly it's under my control but I'm fighting my own lack of = abilities, trying to sprint a marathon before I can even crawl. Looking = at kernel sources when I can barely get 'hello world' to compile & run = is asking for trouble :-) About a day ago I didn't know what an SKB = was. = https://www.coverfire.com/articles/queueing-in-the-linux-network-stack/ = has been a revelation. This sounds like you embark on fixing the del driver in your = modem; more power to you then. Best Regards Sebastian >>=20 >> Best Regards >> Sebastian >>=20 >=20 >=20