From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) (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 E1A7621F617 for ; Sat, 6 Jun 2015 07:29:22 -0700 (PDT) Received: from hms-beagle-6.home.lan ([217.237.71.188]) by mail.gmx.com (mrgmx002) with ESMTPSA (Nemesis) id 0Lxxw4-1Z70IL3NmG-015F9u; Sat, 06 Jun 2015 16:29:18 +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: <5572F7E0.3060602@darbyshire-bryant.me.uk> Date: Sat, 6 Jun 2015 16:29:15 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <0A0D06AB-CC83-4D99-80C6-8E7822C8707C@gmx.de> References: <5572F7E0.3060602@darbyshire-bryant.me.uk> To: Kevin Darbyshire-Bryant X-Mailer: Apple Mail (2.1878.6) X-Provags-ID: V03:K0:sfpDH+7H+lObUKcMzDJCSZbxEeJ2YINkkbeV0PO2PZqVNVni6Fx aXBtkNO6MGH6hYpPahYNnpa+/AUGRD9qDmmE7gBbeGxS4fmroqkCKITSjGl/ndw6jEt9j/C Y4VBnElfJBq3lhRu1unj4d2/hQnOOy+kk1aPxkTbnPlfTdlhV2Wds85ByL6s2fK5xXoGOVc jof+R/wioBCRaAt4f1NGQ== X-UI-Out-Filterresults: notjunk:1;V01:K0:koDdXkuGRaE=:CDRN709pjWKS15pMvr//7K 0w82XKbl/GZaOGAOtD4KcQE1ANnd3h/B/qhapjuFgCkMxRwIyvGHoCX/JpSHE0zSBfylMP9HU xEiE7bGDiwS9zaJ/6HySlg2nYcNu7tmldk5ZwmSEUUcuIUJgZEClN/YbSBQo2oJGFcGE3f4PM RcAaboK4HwiO7/KJdY5PZMfSO48tIIj39CVaRJe+uV14hPMT9Y0IJXu3LAN2uPhn/wQcIqiik Sfouw2QzUNXEYPVZG9cJ0wZ5FdxlNjbxRWyT8RVP3/xTU6f/eGNkq9YPSb+2uSNxWsd5qWqXo xYaGhM7+RD399yY6sBjhSnaIHzeUTRT5uZQ5pJgbQ+ZWgwzPLMgXMBR6jt9JiYBhB75YbICB+ 9mVLovHMBgyWP10czZKw+9I/o4C1EuZUwFtn8SRlGm93WeL2OhXxswWqnJmtunyqaRjx/R/XC +2zLX/S0LbXFiGFMUsvahLwVGReYiJ6QTfBuxUH9ZO2GzfNKoE41aS0+abOu0QAkbhLLsxQL4 8XzlVwJjjgXuKd9fy7Wk06Hbdo5gVYozJYOH1m77JNOgUUrTfOMT/TwnW5FWvJgk3QxvR6X1l 0rMfjixRI4oG4ZLHk6ZB+XG1A7Yce1/bNS5q2vf1RFU8kfWOdzk8Ghv7xYSkjbaloMEvQZG4o S32qIjPbC99wHLipbNR2XEmG99YQ06VJblph9p4Wjs/+6vGL11FImphgK4U2+rlR6Qtc= 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 14:29:51 -0000 Hi Kevin, On Jun 6, 2015, at 15:38 , Kevin Darbyshire-Bryant = wrote: > Hi Chaps, >=20 > Guess who :-) Following on from my probably rash assertion that BT = here in the UK probably aren't as bad at bufferbloat from them to end = user due to rate limiting as I think, it has reminded me of my parents' = situation and efforts to help them. >=20 > Scenario is: ADSL very long line (hopefully they've got the copper = repaired now) so on a good day the ADSL sync is something like 2Mbit = down, 512kbit up. I bought them a Netgear DGN3500 which is now running = OpenWrt CC (+cake) This is not my preferred solution in hardware terms = but it has a supported built-in ADSL modem so is a one box solution. >=20 > The problem I have is setting outbound rate limiting. I was hoping = that 'cake' without the 'bandwidth' parameter would work on the = 'backpressure' from the ATM(?) driver, sadly this wasn't the case and so = setting a bandwidth limit (I'm not in a position to test the new = keywords for ATM encapsulation etc yet) was the only way forward. =20 This is rather important to get right, ATM=92s arcane 48/53 = encapsulation only leaves 100*48/53 =3D 90.5% of the sync rate for = useable bits, and even those need to contain all the headers specific to = your line (plus AAL5=92s unfortunate choice of fitting each packet into = an integer number of ATM cells), mean that without AQM taking the link = layer encapsulation into account you need to aim for roughly 80-85% of = the sync rates on and ATM link. With a link that disappears often I = currently would recommend sqm-scripts as weapon of choice (you should be = able to get cake into sqm-scripts) as the IFB needs to be set up again = after the =93connected=94 interface reappears, which current sqm-scripts = should do for you... > Unfortunately the ADSL link isn't rock solid stable so the negotiated = rates for in & out flap around a bit. So a few questions: That is bad and will need special care; on the positive side we = might be able to include your solution for this issue into sqm-scripts = so that this only needs solving/working-around once ;) >=20 > 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. > 2) Do byte queue limits apply to outbound only? Don=92t know, they certainly affect outbound on drivers that = actually implement that feature, as far as I know all ethernet so far. > 3) Horrid thought - this probably isn't just the ATM driver as IP is = provisioned over PPP. PPP driver needs BQL too? Don=92t think so, I have cerowrt terminating a PPPoE link and = outbound shaping just works as expected. Then again I actually have a = shaper set to 95% of the sync rate, but that is caused by my ISP being = daft and implementing a throttle at the BRAS level which I need to = target for shaping, but that=92s why I do not reach 100% on egress ;) = YMMV. >=20 >=20 > So another approach is to query the ATM interface on every IF up = (which should get reflected into the the PPP interface up) for its = current negotiated sync rates and use those as input into the SQM = scripts. That sounds like a decent approach, but why not simply do this = every hour instead/in addition? >=20 > There's a question here that's niggling me at the back of my mind: How = is this supposed to work with a two box modem and router solution? I = guess the modem should ideally be running some sort of outbound AQM and = dropping packets on its ethernet interface that just won't fit/queue too = long. 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 Best Regards Sebastian >=20 > Sorry, too many questions and I've not enough programming experience = let alone linux kernel experience to be able to help. I'll try if = someone can point me in a direction. >=20 > Kevin >=20 >=20 >=20 > _______________________________________________ > Bloat mailing list > Bloat@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/bloat