Hi, > Le 21 avr. 2020 à 20:44, Dave Taht <[email protected]> a écrit : > > It has always been my dream, that at least for outbound, there would > be sufficient backpressure from the driver > to not have to shape at all, or monitor the link. We have that now in > BQL and AQL. free.fr's dsl driver "does the right thing" - no other > dsl driver does.
My curiosity is piqued. Can you elaborate on this? What does free.fr <http://free.fr/> do? Thanks, Thibaut > Nor usb network devices. I hope more folk roll up > their sleeves and test the ath10k some, it's looking lovely from here. > > https://forum.openwrt.org/t/aql-and-the-ath10k-is-lovely/ > > next up either the new mediatek chip or intel.. > > On Tue, Apr 21, 2020 at 11:40 AM Jonathan Morton <[email protected]> > wrote: >> >>> On 21 Apr, 2020, at 9:22 pm, Justin Kilpatrick <[email protected]> wrote: >>> >>> I have a frequently changing link I'm using automated tools to monitor and >>> tune using Cake. Currently I'm only tuning bandwidth parameter using >>> latency and packet loss data. >>> >>> My reading of the codel RFC seems to say that trying to tune the 'interval' >>> value using known path and link latency won't provide any advantages over >>> just tuning the bandwidth parameter. >>> >>> Obviously codel is just one part of the Cake setup and I'm wondering if >>> there are any advantages I'm missing by not providing this extra input >>> using data I already gather. >> >> The default latency parameters are tuned well for general Internet paths. >> The median path length on the public Internet is about 80ms, for which the >> default interval of 100ms and target of 5ms works well. Codel is also >> designed to accommodate a significant deviation from the expected path >> length without too much difficulty. >> >> I think it's only worth trying to adjust this if your typical path is >> substantially different from that norm. If all your traffic goes over a >> satellite link, for example, the default parameters might be too tight. If >> the vast majority of it goes to a local CDN, you could try the "metro" >> keyword to tighten things up a bit. Otherwise, you'll be fine. >> >> Also, most protocols are actually not very sensitive to how tight the AQM is >> set in the first place. Either they don't really care about latency at all >> (eg. bulk downloads) or they are latency-sensitive but also sparse (eg. DNS, >> NTP, VoIP). So they are more interested in being isolated from the >> influence of other flows, which Cake does pretty well regardless of the AQM >> settings. >> >> It's *considerably* more important to ensure that your shaper is configured >> correctly. That means setting not only the bandwidth parameter, but the >> overhead parameters as well. A bad shaper setting could result in some or >> all of your traffic not seeing Cake as the effective bottleneck, and thus >> not receiving its care. This can be an orders-of-magnitude effect, >> depending on just how bloated the underlying hardware is. >> >> - Jonathan Morton >> _______________________________________________ >> Cake mailing list >> [email protected] >> https://lists.bufferbloat.net/listinfo/cake > > > > -- > Make Music, Not War > > Dave Täht > CTO, TekLibre, LLC > http://www.teklibre.com > Tel: 1-831-435-0729 > _______________________________________________ > Cake mailing list > [email protected] > https://lists.bufferbloat.net/listinfo/cake
_______________________________________________ Cake mailing list [email protected] https://lists.bufferbloat.net/listinfo/cake
