From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-io1-xd33.google.com (mail-io1-xd33.google.com [IPv6:2607:f8b0:4864:20::d33]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 97CB93B29D for ; Tue, 21 Apr 2020 14:45:05 -0400 (EDT) Received: by mail-io1-xd33.google.com with SMTP id e9so8527906iok.9 for ; Tue, 21 Apr 2020 11:45:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=qaVr5qV5XK+eNleFJqyGv5nLtnd1470HUzuGruMBuyg=; b=XWT3GouBQDqksBryuwcJJ6tbnNWOOIEuh6g/4rynO+2RAPNVUNPXTSKosyK1vuFaap zSljFtIhbvHRBev0DySM6cDqht6jIQXQfrBPKG8TI6bLKrDyYkHynWyS/otTyosaqhGM jWZe+YQoicjf06QPpoyAUcfEZ8GXE9Iiq+7CZbGMYvQD7pOAt5Fy58V+ThBx/pM6t/l8 uCHlI59RvSfz+zXnry1KyY5XGDwB5zMvr0ULvDHufGsLB4LEUvDfWJ/LBJ7PvMqvsdK6 y/h3VEuDN6Co6HaWk5jLduyTSQl9hHPpaXKZioJswQi6fMXOJcorcKKc89kXA35KvSl0 iehQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=qaVr5qV5XK+eNleFJqyGv5nLtnd1470HUzuGruMBuyg=; b=EOhq3oGufUwjxhQ9bGNBAPsYv9U7nmABs150a72zOOD9xepHGTaxvH5u3hdWQGaHn7 DPIqB5A0Ke1qNF+B71x9rrBeGdaZZCRSPjzP7FB0JuJMSLwf4Tka5FiehTZjJsNQ7pGT Gxm6VRSGBMMc/mTofd/rfmv9oSqq7Zr7EI/B1sidWHOgJv20jHNKRVdezbcEZEeFTUIZ xdfTuSqBdj4KrUyKbUTnyWAtFSTTYXkMu3in7h0xE4YUenoGY+iV+5zCaTRe+Wtna1gy ltE5sgQn8PmWQXfXCQSYUXu/ogZNSNsdwAIfkRV25F2O0WUieX+pXmrb9UlH4tRPZ9wy AXgQ== X-Gm-Message-State: AGi0PubDS/EGNb5klMGW0K+y/Kdgwebol4CjhNgPzCFR+x1sTC6ZBubI P4j2658usbKVTPQBiRLn8ZXUs8Gji28itJQmWG9Y9PFcoJE= X-Google-Smtp-Source: APiQypIt7lS1c5IyDEyujpZiHnnToDgoWxmKgws5sxUeyXE2ZYC2bJMhw6SkMpEYjsxUagbdQEY9ystHv2Xae7ghXMo= X-Received: by 2002:a6b:b8d6:: with SMTP id i205mr22960880iof.123.1587494704923; Tue, 21 Apr 2020 11:45:04 -0700 (PDT) MIME-Version: 1.0 References: <75FEC2D9-BFC8-4FA2-A972-D11A823C5528@gmail.com> In-Reply-To: <75FEC2D9-BFC8-4FA2-A972-D11A823C5528@gmail.com> From: Dave Taht Date: Tue, 21 Apr 2020 11:44:52 -0700 Message-ID: To: Jonathan Morton Cc: Justin Kilpatrick , Cake List Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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 18:45:05 -0000 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. 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 wr= ote: > > > On 21 Apr, 2020, at 9:22 pm, Justin Kilpatrick wrot= e: > > > > 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 la= tency and packet loss data. > > > > My reading of the codel RFC seems to say that trying to tune the 'inter= val' value using known path and link latency won't provide any advantages o= ver 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 usi= ng 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 th= e default interval of 100ms and target of 5ms works well. Codel is also de= signed 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 sub= stantially different from that norm. If all your traffic goes over a satel= lite 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 configur= ed 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, dependi= ng on just how bloated the underlying hardware is. > > - Jonathan Morton > _______________________________________________ > Cake mailing list > Cake@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/cake --=20 Make Music, Not War Dave T=C3=A4ht CTO, TekLibre, LLC http://www.teklibre.com Tel: 1-831-435-0729