From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from vps.slashdirt.org (vps.slashdirt.org [144.91.108.218]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 1A7603B29D for ; Tue, 21 Apr 2020 18:25:57 -0400 (EDT) Received: from chuck.tardis.lan (tardis.herebedragons.eu [171.22.3.161]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by vps.slashdirt.org (Postfix) with ESMTPSA id CB526600A9; Wed, 22 Apr 2020 00:25:55 +0200 (CEST) DKIM-Filter: OpenDKIM Filter v2.11.0 vps.slashdirt.org CB526600A9 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=slashdirt.org; s=mail; t=1587507956; bh=rjwKtEOXK4jgpDx9SAm0xlFuoooBKdScOxOD0Ck4vEA=; h=From:Subject:Date:In-Reply-To:Cc:To:References:From; b=r3jEif/zIjxBQPmb8D6oxm3+M3yD6TUnHxQ6JaQzU6yN79i0vRb8GavntVg3nXc64 /opG9ICEsWJCObmLo7W5BJXc+lMVCAkjhO4JRSkGeKOvQWhGtVvwwG8PZmDC1Xl56a 1Oa+KmBrUf0hV9cFbI9Z+UP0YVLuHgfFCqaEbcWA= From: Thibaut Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_5C6C3759-3008-4C78-91B6-B51389B7DCFD" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.14\)) Date: Wed, 22 Apr 2020 00:25:55 +0200 In-Reply-To: Cc: Jonathan Morton , Cake List To: Dave Taht References: <75FEC2D9-BFC8-4FA2-A972-D11A823C5528@gmail.com> X-Mailer: Apple Mail (2.3445.104.14) Subject: Re: [Cake] Advantages to tightly tuning latency X-BeenThere: cake@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: Cake - FQ_codel the next generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Apr 2020 22:25:57 -0000 --Apple-Mail=_5C6C3759-3008-4C78-91B6-B51389B7DCFD Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi, > Le 21 avr. 2020 =C3=A0 20:44, Dave Taht a =C3=A9cr= it : >=20 > 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 = 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. >=20 > https://forum.openwrt.org/t/aql-and-the-ath10k-is-lovely/ >=20 > next up either the new mediatek chip or intel.. >=20 > On Tue, Apr 21, 2020 at 11:40 AM Jonathan Morton = wrote: >>=20 >>> On 21 Apr, 2020, at 9:22 pm, Justin Kilpatrick = wrote: >>>=20 >>> 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. >>>=20 >>> 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. >>>=20 >>> 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. >>=20 >> 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. >>=20 >> 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. >>=20 >> 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. >>=20 >> 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. >>=20 >> - Jonathan Morton >> _______________________________________________ >> Cake mailing list >> Cake@lists.bufferbloat.net >> https://lists.bufferbloat.net/listinfo/cake >=20 >=20 >=20 > --=20 > Make Music, Not War >=20 > Dave T=C3=A4ht > CTO, TekLibre, LLC > http://www.teklibre.com > Tel: 1-831-435-0729 > _______________________________________________ > Cake mailing list > Cake@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/cake --Apple-Mail=_5C6C3759-3008-4C78-91B6-B51389B7DCFD Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi,

Le 21 avr. 2020 =C3=A0 20:44, Dave Taht = <dave.taht@gmail.com> a =C3=A9crit :

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 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@gmail.com> wrote:

On 21 Apr, 2020, at 9:22 pm, Justin Kilpatrick = <justin@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@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cake



-- =
Make Music, Not War

Dave = T=C3=A4ht
CTO, TekLibre, LLC
http://www.teklibre.com
Tel: 1-831-435-0729
_______________________________________________
Cake mailing list
Cake@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cake

= --Apple-Mail=_5C6C3759-3008-4C78-91B6-B51389B7DCFD--