Re: [Cerowrt-devel] [Bloat] Invisibility of bufferbloat and its remedies

[Kevin Darbyshire-Bryant <kevin@darbyshire-bryant.me.uk>]

[-- Attachment #1: Type: text/plain, Size: 4622 bytes --]



> On 20 Jun 2018, at 09:07, Sebastian Moeller <moeller0@gmx.de> wrote:
> 
> Hi Kevin,
> 
> 
>> On Jun 20, 2018, at 09:12, Kevin Darbyshire-Bryant <kevin@darbyshire-bryant.me.uk> wrote:
>> 
>> 
>> 
>>> On 20 Jun 2018, at 00:41, Jonathan Morton <chromatix99@gmail.com> wrote:
>>> 
>>>> On 19 Jun, 2018, at 11:34 pm, valdis.kletnieks@vt.edu wrote:
>>>> 
>>>> Do we have a good cookbook on how to determine the set-rate?
>>> 
>>> 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.
>> 
>> I’ve been experimenting with this hack in sqm-scripts to do just that https://github.com/ldir-EDB0/sqm-scripts/commit/a71ab1c9acd75d6e9254360e832ac7b6f9514e88 originally on my parents DGN3500 and currently on my on BT HomeHub5a test line.
> 
> 	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).
> 
> if [ "pppoa-wan" = "$IFACE" ]; then
> 	if [ -f "/lib/functions/lantiq_dsl.sh" ] : then
> 		...
> 	fi
> fi
> 
> 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).
> 
> 
> 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?
> 
> 
> *) 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?
> 
>> 
>> It fails to work if the ISP does rate banding (BT 20CN does this, BT 21CN doesn’t) where downstream is limited to a rate below downstream sync rate.  I guess a lookup table could be implemented.
> 
> 	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)).
> 
> 
> 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.

What part of ‘hack’ didn’t you understand? ;-)

Luci is a ‘bad’ idea in that setting it there effectively makes the rate fixed again…. and line resyncs do not remain static, so it needs to be a hotplug type solution.

The commit isn’t perfect…it was never meant to make it into the wild…I 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.

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.”

‘Inerface_name’. - and I’m not sure if that isn’t supposed to be expanded to the actual interface name in use - I tried fixing the typo but when the name expansion still didn’t work and I had no idea how to fix that…. I got distracted by something else :-)





[-- Attachment #2: Message signed with OpenPGP --]
[-- Type: application/pgp-signature, Size: 833 bytes --]