Skip to content

Update docs on the limit parameter for FQ_C #811

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 1 commit into from
Nov 27, 2025
Merged

Update docs on the limit parameter for FQ_C #811

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
12 changes: 6 additions & 6 deletions source/manual/how-tos/shaper_bufferbloat.rst
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -337,16 +337,16 @@ limit
Default limit size of 10240 packets is too much. The creators recommended value 1000 for sub 10 Gbit/s connections. The default limit will never be reached for sub 10 Gbit/s WAN connections. Before that could happen FQ_CoDel would already take action. So it is healthy to reduce the limit.

The over-large packet limit leads to bad results during slow start on some benchmarks. Reducing it too low could impact new flow start.

.. Note::

However there is a problem with FQ_CoDel implementation in FreeBSD (as well OpenBSD), that causes CPU hogging and excessive logging, this is more visible when set to 1000. Which causes a back pressure and additional unwanted latency.

**For now its best to have limit at default.**
For FreeBSD there is a `BUG <https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=276890>`_ opened for CPU hogging due to excessive logging caused when the limit queue is exceeded.
Additionaly one of the creators of CoDel raised a `discussion <https://marc.info/?t=170776797300003&r=1&w=2>`_ to improve the implementation of FQ_CoDel on FreeBSD.

.. Note::

There is already a BUG opened for this and an email chain from one of the CoDel creators.
This problem is overall affecting the performance, its not specific only to limit parameter,
and more so the more flows are present
The CPU hogging due to excessive logging was `fixed <https://github.com/opnsense/src/commit/8684f75c425>`_ for OPNsense by the devs on release 25.7.8
Its now safe and beneficial to use the limit parameter and lower it from the default value.


flows
Expand Down