[Cake] Advantages to tightly tuning latency

[Thibaut]

Hi,

> Le 21 avr. 2020 à 20:44, Dave Taht <dave.taht at gmail.com> 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 <chromatix99 at gmail.com> wrote:
>> 
>>> On 21 Apr, 2020, at 9:22 pm, Justin Kilpatrick <justin at althea.net> 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
>> Cake at lists.bufferbloat.net
>> 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
> Cake at lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cake

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.bufferbloat.net/pipermail/cake/attachments/20200422/2593f69d/attachment.html>