From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id C1AE03B29E; Wed, 20 Jun 2018 05:34:13 -0400 (EDT) Received: from [172.16.11.169] ([134.76.241.253]) by mail.gmx.com (mrgmx102 [212.227.17.168]) with ESMTPSA (Nemesis) id 0Lz0aC-1gIBxL3lHk-014Cfc; Wed, 20 Jun 2018 11:34:04 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.4 \(3445.8.2\)) From: Sebastian Moeller In-Reply-To: <2A229D52-1640-4E2C-9814-D12927103244@darbyshire-bryant.me.uk> Date: Wed, 20 Jun 2018 11:34:02 +0200 Cc: Jonathan Morton , "valdis.kletnieks@vt.edu" , "cerowrt-devel@lists.bufferbloat.net" , bloat Content-Transfer-Encoding: quoted-printable Message-Id: <9FC34EAC-8C81-4126-BE49-1F4421DAEDC0@gmx.de> References: <1529339194.276412941@apps.rackspace.com> <1529361825.80979395@apps.rackspace.com> <145517.1529440447@turing-police.cc.vt.edu> <86CE2EF6-D0D2-4384-8FC0-8B7EB20D05BA@darbyshire-bryant.me.uk> <41B72404-6E7D-47F0-B23F-7707EA2CB87E@gmx.de> <2A229D52-1640-4E2C-9814-D12927103244@darbyshire-bryant.me.uk> To: Kevin Darbyshire-Bryant X-Mailer: Apple Mail (2.3445.8.2) X-Provags-ID: V03:K1:riQUSddcOOUb/Nu1xhsp0gppyon+fiC8fG0mXV2QBg3CQuoOGnw hjcJxL2ksBWdA+Qsj1iNKn5N9rPmR+4+va1VKO8SCsXNZDvM3/cxlJOV7+b7d3RJFW9d/Ws mm3L2aNJ9kFiKz/fHc0jbCveKUDzT2BAL3StOPShcm/sbiqbaDDO4RgBdGf+Bd905gM8vo7 w/5WCuOvhq/PUbjvxF6qg== X-UI-Out-Filterresults: notjunk:1;V01:K0:ROBDMyss7qM=:IsyPPa0kOZTbFTNrgYAw99 vNm2bIZXPcl63hG+Ufe4w0PZRTkfPCAjnpinCmqWWWHZ1mU4oTGrs9Ga5GgakVtdV+NxOjmvg 8+FlmhowPBlnvCO8XrwIyVLGFuyZkAII8TIL3bxgoyu6BTAHedbE+1WZVDyqtzBw6P6MDqsH5 4TfoJYfKcBGQjFAHcaliT9inQ8N75GdNeif6oZLBcCm8H9Wy9d1qBZHisBU3LCGpRkFYz2zyX JbeCVGwDsBKAyu6odClvhe94YB5B44BpjD0kKFPdyExPx9MW9YEX1DyfcJGOV7h1QBiHZMZXT NVtEDEtgQb3rI5gMiBVHnSSuxaSGZZ6XPtF5VxiAwuRmWnLKKEjQJAsTQlyS48zeEldFeYn41 zgND5xw5u636cKRpkx9FFp0Sef01iNjDsTjf9csUIcO1cPWYFAoWOvZiUeiGKww/X8fbdg386 9jqyXa5jH4AlxoQjoIuXGBpdjUGpPCYrHHGNFGvV4rAaCOa7EYkKlttir3Lw/Rp/Uw5r+cQu6 6DSeWIzfUcwT7NpqxEGEP4K+BHZI9V9RBN85eo7DfLsLpSpKRWdU3R6DaImUYvZG7isMIxk41 eEChsC5vBXTrArfjZnMfgLonq9bt9qX2i3s5ae+x5vM0oGKFn9b6m2bBs1vVgp8iQRpR0GsBd Owv4volRj2opnXGl8UIHOBURPuqMu39r99v2R/em4vJF3oa8OAszfR3TAi/TT50xRfdTrsbKf 5wwM97it4q+xDur/FaiAINUOQPGTwmThCUBrslzvKvA8YW6HOMoZ0J1irYVUSHq/BmNTupOnq TlpSrZh Subject: Re: [Cerowrt-devel] [Bloat] Invisibility of bufferbloat and its remedies X-BeenThere: cerowrt-devel@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: Development issues regarding the cerowrt test router project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jun 2018 09:34:14 -0000 Hi Kevin, > On Jun 20, 2018, at 11:15, Kevin Darbyshire-Bryant = wrote: >=20 >=20 >=20 >> On 20 Jun 2018, at 09:07, Sebastian Moeller wrote: >>=20 >> Hi Kevin, >>=20 >>=20 >>> On Jun 20, 2018, at 09:12, Kevin Darbyshire-Bryant = wrote: >>>=20 >>>=20 >>>=20 >>>> On 20 Jun 2018, at 00:41, Jonathan Morton = wrote: >>>>=20 >>>>> On 19 Jun, 2018, at 11:34 pm, valdis.kletnieks@vt.edu wrote: >>>>>=20 >>>>> Do we have a good cookbook on how to determine the set-rate? >>>>=20 >>>> On DSL, the sync rates in each direction should usually be readable = from the modem; they are typically reported on the router's status page. = The advertised rate is less reliable, to say the least. >>>=20 >>> I=E2=80=99ve been experimenting with this hack in sqm-scripts to do = just that = https://github.com/ldir-EDB0/sqm-scripts/commit/a71ab1c9acd75d6e9254360e83= 2ac7b6f9514e88 originally on my parents DGN3500 and currently on my on = BT HomeHub5a test line. >>=20 >> Clever (I see how you chiseled data_rates() into shape here, = respect)! Even though I believe that this is not pppoa specific and = should probably check whether /lib/functions/lantiq_dsl.sh exists. = Actually this code will also work on VDSL2 links... (and we should also = be able to extract the encapsulation atm or ptm). >>=20 >> if [ "pppoa-wan" =3D "$IFACE" ]; then >> if [ -f "/lib/functions/lantiq_dsl.sh" ] : then >> ... >> fi >> fi >>=20 >> But would it not be simpler to call /etc/init.d/dsl_control status | = grep -e "Data Rate:" or somesuch? Cureently openwrt only supports = lantiq/intel modems, but if broadcom modems should ever be supported I = venture a guess they will not use /lib/functions/lantiq_dsl.sh to = generate the stats output ;) (not that there is a guarantee that = dsl_control would exost and generate compatible output). >>=20 >>=20 >> But I believe that this is not that helpful as a mode to = automatically set the bandwidth*, as I assume that most ISPs will shape = the downstream bandwidth upstream of the DSLAM (if just to avoid having = a DDOS against one user taking down the whole DSLAM). In my case my ISP = even shapes the upstream, which is somewhat more puzzling. It looks like = a cool way to deal with variable sync (either after a re-sync due to say = DLM action or due to SRA) so how about polishing this a bit and = including this as pure informational line in the log? >>=20 >>=20 >> *) if this is to be made automatic by say allowing to scrape = bandwidth from the modem we would need additional setting for setting = the shaper percentage. I wonder whether all of this is worth it though, = given that the number of users running sqm on devices in control of the = dsl-modem is going to be miniscule, no? >>=20 >>>=20 >>> It fails to work if the ISP does rate banding (BT 20CN does this, BT = 21CN doesn=E2=80=99t) where downstream is limited to a rate below = downstream sync rate. I guess a lookup table could be implemented. >>=20 >> I predict that a lookup table is going to be constantly out of = date, especially since at least my ISP is a moving target in both the = shaper settings as well as the actual overheads (on the plus side they = started to send the applicable net bandwidth as part of the pppoe = negotiations (but failed to document how those rates are actually to be = interpreted ;) win some loose some)). >>=20 >>=20 >> Final thought, how about just using this on the luci side to give = hints about the sync bandwidth in the GUI (like displaying the value of = either sync for xdsl or the speed for ethernet devices (speed in ethtool = parlance, so 10Mb/s, 100Mb/s, ...)) that will not be as smooth as your = solution, but should also be more robust against doing the wrmg thing = automatically? Or am I overcomplicating things again. >=20 > What part of =E2=80=98hack=E2=80=99 didn=E2=80=99t you understand? ;-) I guess your hack have a higher quality than my release patches = ;) >=20 > Luci is a =E2=80=98bad=E2=80=99 idea in that setting it there = effectively makes the rate fixed again=E2=80=A6. Sure. > and line resyncs do not remain static, so it needs to be a hotplug = type solution. from my experience sync rates are typically quite robust, not on = the kbit but close enough given the typical reduction in bandwidth for = the shaper to be active. But here we are just introducing DLM, so I = guess I have a somewhat naive and optimistic view based on my ISPs = conservative profiles and enforced high SNR-margins...=20 >=20 > The commit isn=E2=80=99t perfect=E2=80=A6it was never meant to make it = into the wild=E2=80=A6I explored 2 years or so ago to see if something = like that could be done but was foiled by a BT 20CN banding plan. But = the seed of an idea is there. To grow it needs watering by someone who = can code. Nah, there are always folks that will fix the implementation = (whom am I kidding, it typically is Toke who picks up the slack ;) ) the = challenge is to get the algorithm right. Between your UK link(s?) and my = single DTAG link we might be able to come up with something. The issue = remains though that this still leaves the overhead to be accounted for = and that the number of users that will have a chance to exercise this = feature will be small. On the other hand maybe changing the GUI to set bandwidth and = shaper-percentage as two independent values might be more in line with = our recommendations (set bandwidth to 90% of the contracted bandwidth), = what do you think? >=20 > Incidentally luci sqm scripts typo (and possibly worse/not intended) = "Create log file for this SQM instance under = /var/run/sqm/${Inerface_name}.debug.log. Make sure to delete log files = manually.=E2=80=9D Oops, thanks that is my typo, fixes and pushed upstream. >=20 > =E2=80=98Inerface_name=E2=80=99. - and I=E2=80=99m not sure if that = isn=E2=80=99t supposed to be expanded to the actual interface name in = use - I tried fixing the typo but when the name expansion still didn=E2=80= =99t work and I had no idea how to fix that=E2=80=A6. I got distracted = by something else :-) No, that is not supposed to auto expand, I just happen to like = the shell syntax to denote that something is a variable... Best Regards Sebastian >=20 >=20 >=20 >=20