[Cerowrt-devel] [Bloat] Invisibility of bufferbloat andits remedies

Wed Jun 20 10:28:05 EDT 2018

The best is the enemy of the pretty good.

Isn't there some cumulative lag under load statistic that can be maintained by a pinger sampling lag as a function of current rate (upload and download)? The Pinger would only ping when load is above a threshold, and only count data as valid if load during ping remains above threshold.

If you scatter plot lag times as a function of current load load, there should be a very obvious knee very visible at just above the optimal control limit. 

In Luci, this plot could be shown, covering time since last adjustment. The user then can see what rate to use, and also evidence of the problem. Just one plot and one setting.

-----Original Message-----
From: "Sebastian Moeller" <moeller0 at gmx.de>
Sent: Wed, Jun 20, 2018 at 4:07 am
To: "Kevin Darbyshire-Bryant" <kevin at darbyshire-bryant.me.uk>
Cc: "Kevin Darbyshire-Bryant" <kevin at darbyshire-bryant.me.uk>, "Jonathan Morton" <chromatix99 at gmail.com>, "cerowrt-devel at lists.bufferbloat.net" <cerowrt-devel at lists.bufferbloat.net>, "bloat" <bloat at lists.bufferbloat.net>
Subject: Re: [Cerowrt-devel] [Bloat] Invisibility of bufferbloat andits	remedies

Hi Kevin,

> On Jun 20, 2018, at 09:12, Kevin Darbyshire-Bryant  wrote:
> 
> 
> 
>> On 20 Jun 2018, at 00:41, Jonathan Morton  wrote:
>> 
>>> On 19 Jun, 2018, at 11:34 pm, valdis.kletnieks at 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.

Final final thought ;) since lantig_dsl.sh is quite openwrt specific, maybe we should do the automatic mode inside of the equally openwrt specific /usr/lib/sqm/run instead of in start-sqm that will might also be executed on other platforms?

Best Regards
	Sebastian

> 
> Kevin
> _______________________________________________
> Bloat mailing list
> Bloat at lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/bloat

_______________________________________________
Cerowrt-devel mailing list
Cerowrt-devel at lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cerowrt-devel