From: Evan Mesterhazy <evan.mesterhazy@gmail.com>
To: codel@lists.bufferbloat.net
Subject: [Codel] Do codel or fq-codel need to know the link bandwidth?
Date: Sat, 7 Dec 2024 16:27:26 -0500 [thread overview]
Message-ID: <CAN2qZSN53zHBszcW1-kY5+SLvAVaNAHZnGJeiM1vJJEbbS0VKg@mail.gmail.com> (raw)
[-- Attachment #1: Type: text/plain, Size: 1626 bytes --]
As far as I can tell, the fq-codel algorithm (
https://www.rfc-editor.org/rfc/rfc8290.html) doesn't use link bandwidth as
a parameter. From reading the description, it seems like it should be able
to work without knowing the link bandwidth since it decides to drop packets
based on the amount of time they have waited in a queue. In fact, the
original codel rfc (https://www.rfc-editor.org/rfc/rfc8289#section-4.1)
even says that it's designed to be non-starving and work over variable
bandwidth links.
However, I have noticed that the commercial implementations for at least
two firewalls that I have used (OPNsense and a Unifi gateway) both require
the user to input the upload and download bandwidths of the link.
In OPNsense I tried setting the bandwidth to a large number above the
actual link bandwidth and then manually setting the fq-codel parameters to
their Linux defaults, but that resulted in poor performance. My concern, of
course, is that I'm leaving throughput on the table by artificially
limiting the bandwidth at a value that may be less than the actual
available bandwidth depending on the time of day, etc.
I'm not sure what exactly OPNsense is doing with the bandwidth parameters,
and I've asked on its forum (
https://forum.opnsense.org/index.php?topic=44501.0). My question for all of
you is whether I am misunderstanding something about fq-codel. Does it need
to be configured with the link bandwidth, or can it work nicely in its
default configuration with variable bandwidth links (let's consider a
typical home fiber connection between 300 and 1000 Mbps).
Thanks for any insight you can share.
[-- Attachment #2: Type: text/html, Size: 2225 bytes --]
next reply other threads:[~2024-12-07 21:27 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-12-07 21:27 Evan Mesterhazy [this message]
2024-12-07 22:25 ` Dave Taht
2024-12-07 22:31 ` Dave Taht
2024-12-07 22:57 ` Evan Mesterhazy
2024-12-08 2:53 ` Jonathan Morton
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://lists.bufferbloat.net/postorius/lists/codel.lists.bufferbloat.net/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAN2qZSN53zHBszcW1-kY5+SLvAVaNAHZnGJeiM1vJJEbbS0VKg@mail.gmail.com \
--to=evan.mesterhazy@gmail.com \
--cc=codel@lists.bufferbloat.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox