From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-oa1-x36.google.com (mail-oa1-x36.google.com [IPv6:2001:4860:4864:20::36]) (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 EAD323B29D for ; Sat, 7 Dec 2024 17:32:03 -0500 (EST) Received: by mail-oa1-x36.google.com with SMTP id 586e51a60fabf-29f8d3eeb93so293039fac.0 for ; Sat, 07 Dec 2024 14:32:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1733610723; x=1734215523; darn=lists.bufferbloat.net; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=ffiN4lxYm2lheJIaJFuG3PI9zYkzZXM1FolKkpyeGh4=; b=HhbQV6KWefxoJL5OMISpKRMXVnoq4WKKj+vm81tM+L8P7nEVpp/fQej30rx+t80PHv Kuhlxu7Iiy9Talk5tMLFxgxrIvA7JPNw6DON1hTj9OAITytER3dgVowb/a/ui1W5Rky2 4O2T+V92ATvIDhGRxP3cKAx8fxXkqIXjxsB68Tuh7YktO7Kvu0vwTdTZaixTzLx8IgEs OcBb3M1ioKCEHO0QHIPrVG7D4m+5nmn8Xnv43vTBLRy5PoiAFVo1lgnCHS76ONgfAn9m MX/zpw+03VtNaBdSiw9Jhr7O470u4TIX1Wip+phohE5d2syoFLrefayhpYgB/1lh5zvI /1zg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1733610723; x=1734215523; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=ffiN4lxYm2lheJIaJFuG3PI9zYkzZXM1FolKkpyeGh4=; b=pqyemHEBW4thY5FFLFlFUew7Wd0Hk08E12QeJ20oRYxdF15MQLWD9AVEgYXSqVuoeL Acu06oCfE8D6qV7nNpY60oGHx/0A62Ldq1/udZNpt789m69a3sy62CO5y3sTvdA2SqsL F2N9aDZRDwGf5FPbEWrNYS1SHggPZpgJsWZ8pOhB9gV0WvQQFd2lmyVU81RXvit48RjK 9URpNIfdqtq9U+yM3RXiKqoF+IdamPTl7/au0RQMONPcSOpZcw9GmvR9R75JkIhn2gz0 kyUYjAgPpd9aAeQd5x41+mE9Go5kP866q7+x8P+vstdg0mc4qCencns36PwujH4CkYs5 A0yw== X-Gm-Message-State: AOJu0Yzts2w77BmmbBWHOp0Q/SOJz3SU6711c6NCtYJs5koOujA3tI9C IuEPYTAaKTqzej9lE5cjyg6E8RSUrJWq8uWChRT5YrHu30LaE7ZV17SYFc2AUW9BFr5HZRZj0Ss K9M+IjaVvHA72UPJ/t0XIxNsGx+k= X-Gm-Gg: ASbGncsrPvJShCpcfRAlrXSKr++B2G5gpaG89xC9wUTPrPFV2k09Qtp9kMKS8lxdPUP cJiFEry177stTnJ/Q22fSsasq3EIioZPVhreFgDTGKVrDik95Y3qiHa2kg/Nzx65v/w== X-Google-Smtp-Source: AGHT+IFzygvOoM+Wcp7+Wb0A8NOCUfIKVHEriHKSnvKJU10qPEKVq6WzR0L1+gVlsRfIAhMwPSWKlgeYbVod3qMkHmo= X-Received: by 2002:a05:6870:678a:b0:29e:6f32:6da4 with SMTP id 586e51a60fabf-29f736a8bfamr5810135fac.26.1733610723209; Sat, 07 Dec 2024 14:32:03 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Dave Taht Date: Sat, 7 Dec 2024 14:31:50 -0800 Message-ID: To: Evan Mesterhazy Cc: codel@lists.bufferbloat.net Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Subject: Re: [Codel] Do codel or fq-codel need to know the link bandwidth? X-BeenThere: codel@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: CoDel AQM discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Dec 2024 22:32:04 -0000 "variable bandwidth" requires that the queuing below fq_codel be minimal. For example 5g has enormous device buffers all over the place which we haven't found an answer to aside from nagging the 5g folk to fix it, and "cake-autorate" Linux WiFi had similar problems, fixed now. https://www.cs.kau.se/tohojo/airtime-fairness/ On Sat, Dec 7, 2024 at 2:25=E2=80=AFPM Dave Taht wrot= e: > > Concurrent with the rise of codel was the bql algorithm in linux, and > the combination of the two led to sufficient backpressure for it to > operate at the native rate of the interface. (AQL does a similar job > for wifi). This keeps queuing in the device ring down to what can be > serviced in a single interrupt. > > "Bufferbloat Systematic Analysis": > https://d1wqtxts1xzle7.cloudfront.net/109517412/its2014_bb-libre.pdf > Byte queue limits: https://lwn.net/Articles/469652/ > > BSD has not evolved an equivalent mechanism. Theoretically you could > run it natively but it would have a lot of jitter from a per-packet > device ring. > > Further most ISPs use a non-native rate for their customer interfaces, > either using a policer or FIFO shaper and thus the rise of combatting > that with shaping via fq_codel to slightly below the ISPs' rate to > move the bottleneck to your own hardware. > > We designed CAKE to use a deficit based shaper to be (roughly) the > inverse of a token bucket shaper to get very close to the ISP rate yet > shape well > > LibreQos (Preseem, Paraqum, Bequant) give ISPs a fq_codel or cake based s= haper. > The rightest answer was to have the isp correctly shape the download, > and the uplink device shape the upload. > > The bufferbloat project has never had the resources to tackle BSD. > > These days all of Linux (and OSX) run fq_codel natively. The FIFO is dead= . --=20 Dave T=C3=A4ht CSO, LibreQos