Re: [Cerowrt-devel] [Bloat] Invisibility of bufferbloat and its remedies
Hi Kevin, > On Jun 20, 2018, at 11:15, Kevin Darbyshire-Bryant > wrote: > > > >> On 20 Jun 2018, at 09:07, Sebastian Moeller wrote: >> >> 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.kletni...@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
Re: [Cerowrt-devel] [Bloat] Invisibility of bufferbloat and its remedies
> On 20 Jun 2018, at 09:07, Sebastian Moeller wrote:
>
> 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.kletni...@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 :-)
signature.asc
Description: Message signed with OpenPGP
___
Cerowrt-devel mailing list
Cerowrt-devel@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cerowrt-devel
Re: [Cerowrt-devel] [Bloat] Invisibility of bufferbloat and its 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.kletni...@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 > bl...@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/bloat ___ Cerowrt-devel mailing list Cerowrt-devel@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/cerowrt-devel
Re: [Cerowrt-devel] [Bloat] Invisibility of bufferbloat and its remedies
> On 20 Jun 2018, at 00:41, Jonathan Morton wrote: > >> On 19 Jun, 2018, at 11:34 pm, valdis.kletni...@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. 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. Kevin signature.asc Description: Message signed with OpenPGP ___ Cerowrt-devel mailing list Cerowrt-devel@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/cerowrt-devel
Re: [Cerowrt-devel] [Bloat] Invisibility of bufferbloat and its remedies
On June 20, 2018 1:41:19 AM GMT+02:00, Jonathan Morton wrote: >> On 19 Jun, 2018, at 11:34 pm, valdis.kletni...@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. Well many ISPs nowadays employ additional traffic shapers upstream of the dslam/MSAN, and it is this shaper's set-rate we would need to have. All we know is that this needs to be <= sync but the details differ. Also we need information about per packet overhead which again is not easily available for end-users. IMHO our best bet would be to get regulatory agancies to force ISPs to make this information easily available to end-users so that customers can actually compare different offers realistically, but I am not holding my breath for this to happen in my lifetime... Best Regards Sebastian > >On wireless links, all bets are off - even with stationary endpoints, >link capacity varies wildly over time. This needs to be solved in the >radio-modems. > >If it's wifi, however, a link-rate-independent solution now exists for >certain hardware, and there's nothing theoretically stopping something >similar being put into future HardMAC implementations. If we get the >choice of hardware, naturally we choose wisely. > > - Jonathan Morton > >___ >Bloat mailing list >bl...@lists.bufferbloat.net >https://lists.bufferbloat.net/listinfo/bloat -- Sent from my Android device with K-9 Mail. Please excuse my brevity. ___ Cerowrt-devel mailing list Cerowrt-devel@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/cerowrt-devel
Re: [Cerowrt-devel] [Bloat] Invisibility of bufferbloat and its remedies
No doubt. However, sometimes one can get powerful economic forces to support good ideas. The entire telecom industry was going after the Internet as a concept fiercely in the days of "dialup" Internet access. Trying to get the government to allow them to price it out of existence, trying to argue that ISDN couldn't be deployed, trying to argue that "selective content" (AOL) was better than the dangerous open Internet full of kiddy porn and drug cartels, whereas Ma Bell et al. would deliver clean and wholesome content only, if the government would just allow them to build the National Inofmration Superhighway the way it "should be engineered". Yet, the Internet community routed around all of this, by showing hugely valuable new ideas that were available instantly, and a vibrant ecosystem of innovators working for users, not for the big companies. It's still reasonable to continute that path. But it is worth remembering that when Venture Capital joined in, things started to go awry. @Home (done by Milo Medin - funded by Kleiner Perkins, now at Google) was conceived as a closed, walled garden, instituting "web caching" that was supposedly "good for users", whie at the same time breaking the WWW protocols needed for evolution of the Internet, and instituting systematic port blocking that prevented anyone from creating servers. But Medin and Kleiner were failures, not getting that openness was at the core of the Internet. -Original Message- From: "Jonathan Morton" Sent: Monday, June 18, 2018 7:17pm To: "dpr...@deepplum.com" Cc: "Dave Taht" , cerowrt-devel@lists.bufferbloat.net, "bloat" Subject: Re: [Bloat] Invisibility of bufferbloat and its remedies > On 19 Jun, 2018, at 1:43 am, dpr...@deepplum.com wrote: > > So, no, the Network Neutrality people are NOT the problem with Bufferbloat. No, but I think it's fair to point towards corporate greed and political ignorance as common causes of both problems. - Jonathan Morton ___ Cerowrt-devel mailing list Cerowrt-devel@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/cerowrt-devel
Re: [Cerowrt-devel] [Bloat] Invisibility of bufferbloat and its remedies
> On 19 Jun, 2018, at 1:43 am, dpr...@deepplum.com wrote: > > So, no, the Network Neutrality people are NOT the problem with Bufferbloat. No, but I think it's fair to point towards corporate greed and political ignorance as common causes of both problems. - Jonathan Morton ___ Cerowrt-devel mailing list Cerowrt-devel@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/cerowrt-devel
