From 58329952281f7a8e829f3bd1a1aaea53529715ce Mon Sep 17 00:00:00 2001 From: SeimusS <126393602+SeimusS@users.noreply.github.com> Date: Thu, 27 Nov 2025 19:28:03 +0100 Subject: [PATCH] Update docs on the limit parameter for FQ_C * Using the limit parameter caused excessive logging and CPU hogging, this was fixed on 25.7.8 * As a result of this fix we can now properly use the limit parameter * Adjusted documentation to reflect current status --- source/manual/how-tos/shaper_bufferbloat.rst | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/source/manual/how-tos/shaper_bufferbloat.rst b/source/manual/how-tos/shaper_bufferbloat.rst index b82215b45..c6c08e23e 100644 --- a/source/manual/how-tos/shaper_bufferbloat.rst +++ b/source/manual/how-tos/shaper_bufferbloat.rst @@ -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 `_ 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 `_ 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 `_ 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