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

[Sebastian Moeller]

Hi Kevin,


> On Jun 20, 2018, at 11:15, Kevin Darbyshire-Bryant <kevin at darbyshire-bryant.me.uk> wrote:
> 
> 
> 
>> On 20 Jun 2018, at 09:07, Sebastian Moeller <moeller0 at gmx.de> wrote:
>> 
>> Hi Kevin,
>> 
>> 
>>> On Jun 20, 2018, at 09:12, Kevin Darbyshire-Bryant <kevin at darbyshire-bryant.me.uk> wrote:
>>> 
>>> 
>>> 
>>>> On 20 Jun 2018, at 00:41, Jonathan Morton <chromatix99 at gmail.com> 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.
> 
> What part of ‘hack’ didn’t you understand? ;-)

	I guess your hack have a higher quality than my release patches ;)


> 
> Luci is a ‘bad’ idea in that setting it there effectively makes the rate fixed again….

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

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

	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?


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

	Oops, thanks that is my typo, fixes and pushed upstream.

> 
> ‘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 :-)

	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


> 
> 
> 
>