Bottom line: Choose the shaping rate from an agreed tradeoff between throughput and latency during load. Keep download and upload observations separate, and preserve the unshaped baseline so the owner can assess what changed.
\nThe OPNsense FQ_CoDel guide describes separate download and upload pipes, queues and rules. Its tuning procedure begins with several unshaped speed tests to record average rates and latency, then uses an initial bandwidth setting of 85 percent of the advertised rate. The procedure raises a directional bandwidth setting while latency remains low and backs it off when latency increases, then repeats for the other direction.
\nThe example and starting percentage do not establish suitable values for a particular circuit. This article concerns the documented bandwidth-tuning decision, not a universal queue profile. DSE leaves other advanced parameters, service-level claims and application acceptance subject to their own evidence.
\nThe following steps are DSE recommendations based on the cited source.
\nDSE recommends an initial worksheet with separate upload and download columns. Record the circuit description, current shaping configuration, test endpoint, time and ordinary workload conditions. Run an approved unshaped baseline before choosing a proposed setting. Keep all baseline observations, including an inconvenient slow or variable result, instead of selecting only the best-looking sample.
\nUse an attended trial with one controlled bandwidth adjustment at a time. For a proposed example, compare a baseline, a conservative shaping setting and a cautiously higher setting using the same method. Have the reviewer decide which latency change warrants backing off. Treat the percentage in the guide as a documented starting procedure rather than a substitute for that local decision.
\nKeep the two directions distinct through the review and retain the actual final values. Avoid changing unrelated queue parameters during the same trial unless the expanded scope has its own justification. After the directional tuning, ask the application owner to assess representative calls, interactive work or transfers under the approved observation plan. Do not infer an application result solely from a speed-test grade.
\nKeep simultaneous and single-direction load trials separately labeled if both are approved. State which trial drives the acceptance decision and why. Review any busy-period observation on its own terms rather than blending all readings into one favorable average.
\nProposed verification: repeat the chosen test at each recorded setting and compare the resulting rate and latency observations with the unshaped baseline. Annotate competing workload, any interruption and any method change. Use the same test service throughout the comparison unless a separate check explains why another endpoint is needed.
\nRetain the sequence of settings and observations so a second administrator can identify the selected tradeoff. Include a return to the previous setting if the pilot becomes unacceptable, then verify the restored configuration. Record the application owner’s observed acceptance separately. Reopen the tuning decision after a circuit-rate or traffic-path change rather than assuming the earlier values remain suitable.
\nSource review completed October 28, 2026. Recheck the official documentation and deployment-specific applicability before a production change.
\n", "content_text": "Bottom line: Choose the shaping rate from an agreed tradeoff between throughput and latency during load. Keep download and upload observations separate, and preserve the unshaped baseline so the owner can assess what changed.\nSource fact: what the authority says\nThe OPNsense FQ_CoDel guide describes separate download and upload pipes, queues and rules. Its tuning procedure begins with several unshaped speed tests to record average rates and latency, then uses an initial bandwidth setting of 85 percent of the advertised rate. The procedure raises a directional bandwidth setting while latency remains low and backs it off when latency increases, then repeats for the other direction.\nWhat the source does not establish\nThe example and starting percentage do not establish suitable values for a particular circuit. This article concerns the documented bandwidth-tuning decision, not a universal queue profile. DSE leaves other advanced parameters, service-level claims and application acceptance subject to their own evidence.\nApplicability questions\n\nWhich link and direction form the intended bottleneck, including any separate upstream equipment?\nWhat repeatable test and observation interval will represent the operational concern?\nWhat throughput and loaded-latency tradeoff will the service owner accept?\nWho can authorize test load, observe user impact and restore the prior shaping settings?\n\nDSE recommendation: controlled next steps\nThe following steps are DSE recommendations based on the cited source.\nDSE recommends an initial worksheet with separate upload and download columns. Record the circuit description, current shaping configuration, test endpoint, time and ordinary workload conditions. Run an approved unshaped baseline before choosing a proposed setting. Keep all baseline observations, including an inconvenient slow or variable result, instead of selecting only the best-looking sample.\nUse an attended trial with one controlled bandwidth adjustment at a time. For a proposed example, compare a baseline, a conservative shaping setting and a cautiously higher setting using the same method. Have the reviewer decide which latency change warrants backing off. Treat the percentage in the guide as a documented starting procedure rather than a substitute for that local decision.\nKeep the two directions distinct through the review and retain the actual final values. Avoid changing unrelated queue parameters during the same trial unless the expanded scope has its own justification. After the directional tuning, ask the application owner to assess representative calls, interactive work or transfers under the approved observation plan. Do not infer an application result solely from a speed-test grade.\nKeep simultaneous and single-direction load trials separately labeled if both are approved. State which trial drives the acceptance decision and why. Review any busy-period observation on its own terms rather than blending all readings into one favorable average.\nVerification and evidence\nProposed verification: repeat the chosen test at each recorded setting and compare the resulting rate and latency observations with the unshaped baseline. Annotate competing workload, any interruption and any method change. Use the same test service throughout the comparison unless a separate check explains why another endpoint is needed.\nRetain the sequence of settings and observations so a second administrator can identify the selected tradeoff. Include a return to the previous setting if the pilot becomes unacceptable, then verify the restored configuration. Record the application owner’s observed acceptance separately. Reopen the tuning decision after a circuit-rate or traffic-path change rather than assuming the earlier values remain suitable.\nOfficial references\n\nOPNsense — Fighting Bufferbloat with FQ_CoDel — official product documentation; confirm the installed release and configuration.\n\nSource review completed October 28, 2026. Recheck the official documentation and deployment-specific applicability before a production change.", "content_markdown": "Bottom line: Choose the shaping rate from an agreed tradeoff between throughput and latency during load. Keep download and upload observations separate, and preserve the unshaped baseline so the owner can assess what changed.\n\n## Source fact: what the authority says\n\nThe [OPNsense FQ_CoDel guide](https://docs.opnsense.org/manual/how-tos/shaper_bufferbloat.html) describes separate download and upload pipes, queues and rules. Its tuning procedure begins with several unshaped speed tests to record average rates and latency, then uses an initial bandwidth setting of 85 percent of the advertised rate. The procedure raises a directional bandwidth setting while latency remains low and backs it off when latency increases, then repeats for the other direction.\n\n## What the source does not establish\n\nThe example and starting percentage do not establish suitable values for a particular circuit. This article concerns the documented bandwidth-tuning decision, not a universal queue profile. DSE leaves other advanced parameters, service-level claims and application acceptance subject to their own evidence.\n\n## Applicability questions\n\n- Which link and direction form the intended bottleneck, including any separate upstream equipment?\n\n- What repeatable test and observation interval will represent the operational concern?\n\n- What throughput and loaded-latency tradeoff will the service owner accept?\n\n- Who can authorize test load, observe user impact and restore the prior shaping settings?\n\n## DSE recommendation: controlled next steps\n\nThe following steps are DSE recommendations based on the cited source.\n\nDSE recommends an initial worksheet with separate upload and download columns. Record the circuit description, current shaping configuration, test endpoint, time and ordinary workload conditions. Run an approved unshaped baseline before choosing a proposed setting. Keep all baseline observations, including an inconvenient slow or variable result, instead of selecting only the best-looking sample.\n\nUse an attended trial with one controlled bandwidth adjustment at a time. For a proposed example, compare a baseline, a conservative shaping setting and a cautiously higher setting using the same method. Have the reviewer decide which latency change warrants backing off. Treat the percentage in the guide as a documented starting procedure rather than a substitute for that local decision.\n\nKeep the two directions distinct through the review and retain the actual final values. Avoid changing unrelated queue parameters during the same trial unless the expanded scope has its own justification. After the directional tuning, ask the application owner to assess representative calls, interactive work or transfers under the approved observation plan. Do not infer an application result solely from a speed-test grade.\n\nKeep simultaneous and single-direction load trials separately labeled if both are approved. State which trial drives the acceptance decision and why. Review any busy-period observation on its own terms rather than blending all readings into one favorable average.\n\n## Verification and evidence\n\nProposed verification: repeat the chosen test at each recorded setting and compare the resulting rate and latency observations with the unshaped baseline. Annotate competing workload, any interruption and any method change. Use the same test service throughout the comparison unless a separate check explains why another endpoint is needed.\n\nRetain the sequence of settings and observations so a second administrator can identify the selected tradeoff. Include a return to the previous setting if the pilot becomes unacceptable, then verify the restored configuration. Record the application owner’s observed acceptance separately. Reopen the tuning decision after a circuit-rate or traffic-path change rather than assuming the earlier values remain suitable.\n\n## Official references\n\n- [OPNsense — Fighting Bufferbloat with FQ_CoDel](https://docs.opnsense.org/manual/how-tos/shaper_bufferbloat.html) — official product documentation; confirm the installed release and configuration.\n\nSource review completed October 28, 2026. Recheck the official documentation and deployment-specific applicability before a production change." }, "json_ld": { "@context": "https://schema.org", "@graph": [ { "@type": "Organization", "@id": "https://dsesecurity.com/#organization", "name": "Detection Systems & Engineering", "alternateName": "DSE Security", "url": "https://dsesecurity.com/", "logo": { "@type": "ImageObject", "url": "https://update.dsesecurity.com/assets/dse-logo-20260812.png?v=1.8.20" } }, { "@type": "Organization", "@id": "https://update.dsesecurity.com/#editorial-team", "name": "DSE Security Editorial Team", "url": "https://update.dsesecurity.com/", "parentOrganization": { "@id": "https://dsesecurity.com/#organization" } }, { "@type": "WebSite", "@id": "https://update.dsesecurity.com/#website", "name": "DSE Updates", "alternateName": "DSE Security Knowledge Hub", "url": "https://update.dsesecurity.com/", "inLanguage": "en-US", "publisher": { "@id": "https://dsesecurity.com/#organization" }, "potentialAction": { "@type": "SearchAction", "target": { "@type": "EntryPoint", "urlTemplate": "https://update.dsesecurity.com/?q={search_term_string}" }, "query-input": "required name=search_term_string" } }, { "@type": "WebPage", "@id": "https://update.dsesecurity.com/updates/tune-opnsense-fq-codel-bandwidth-against-latency-under-load/", "url": "https://update.dsesecurity.com/updates/tune-opnsense-fq-codel-bandwidth-against-latency-under-load/", "isPartOf": { "@id": "https://update.dsesecurity.com/#website" }, "lastReviewed": "2026-10-28" }, { "@type": "BreadcrumbList", "@id": "https://update.dsesecurity.com/updates/tune-opnsense-fq-codel-bandwidth-against-latency-under-load/#breadcrumbs", "itemListElement": [ { "@type": "ListItem", "position": 1, "name": "DSE Updates", "item": "https://update.dsesecurity.com/" }, { "@type": "ListItem", "position": 2, "name": "IT", "item": "https://update.dsesecurity.com/topic/it/" }, { "@type": "ListItem", "position": 3, "name": "Tune OPNsense FQ_CoDel bandwidth against latency under load", "item": "https://update.dsesecurity.com/updates/tune-opnsense-fq-codel-bandwidth-against-latency-under-load/" } ] }, { "@type": [ "Article", "TechArticle" ], "@id": "https://update.dsesecurity.com/updates/tune-opnsense-fq-codel-bandwidth-against-latency-under-load/#article", "identifier": "https://update.dsesecurity.com/updates/tune-opnsense-fq-codel-bandwidth-against-latency-under-load/", "url": "https://update.dsesecurity.com/updates/tune-opnsense-fq-codel-bandwidth-against-latency-under-load/", "headline": "Tune OPNsense FQ_CoDel bandwidth against latency under load", "description": "The OPNsense FQ_CoDel guide tunes upload and download rates against latency under load; use local measurements rather than copying its example bandwidth.", "abstract": "The OPNsense FQ_CoDel guide tunes upload and download rates against latency under load; use local measurements rather than copying its example bandwidth.", "articleBody": "Bottom line: Choose the shaping rate from an agreed tradeoff between throughput and latency during load. Keep download and upload observations separate, and preserve the unshaped baseline so the owner can assess what changed.\nSource fact: what the authority says\nThe OPNsense FQ_CoDel guide describes separate download and upload pipes, queues and rules. Its tuning procedure begins with several unshaped speed tests to record average rates and latency, then uses an initial bandwidth setting of 85 percent of the advertised rate. The procedure raises a directional bandwidth setting while latency remains low and backs it off when latency increases, then repeats for the other direction.\nWhat the source does not establish\nThe example and starting percentage do not establish suitable values for a particular circuit. This article concerns the documented bandwidth-tuning decision, not a universal queue profile. DSE leaves other advanced parameters, service-level claims and application acceptance subject to their own evidence.\nApplicability questions\n\nWhich link and direction form the intended bottleneck, including any separate upstream equipment?\nWhat repeatable test and observation interval will represent the operational concern?\nWhat throughput and loaded-latency tradeoff will the service owner accept?\nWho can authorize test load, observe user impact and restore the prior shaping settings?\n\nDSE recommendation: controlled next steps\nThe following steps are DSE recommendations based on the cited source.\nDSE recommends an initial worksheet with separate upload and download columns. Record the circuit description, current shaping configuration, test endpoint, time and ordinary workload conditions. Run an approved unshaped baseline before choosing a proposed setting. Keep all baseline observations, including an inconvenient slow or variable result, instead of selecting only the best-looking sample.\nUse an attended trial with one controlled bandwidth adjustment at a time. For a proposed example, compare a baseline, a conservative shaping setting and a cautiously higher setting using the same method. Have the reviewer decide which latency change warrants backing off. Treat the percentage in the guide as a documented starting procedure rather than a substitute for that local decision.\nKeep the two directions distinct through the review and retain the actual final values. Avoid changing unrelated queue parameters during the same trial unless the expanded scope has its own justification. After the directional tuning, ask the application owner to assess representative calls, interactive work or transfers under the approved observation plan. Do not infer an application result solely from a speed-test grade.\nKeep simultaneous and single-direction load trials separately labeled if both are approved. State which trial drives the acceptance decision and why. Review any busy-period observation on its own terms rather than blending all readings into one favorable average.\nVerification and evidence\nProposed verification: repeat the chosen test at each recorded setting and compare the resulting rate and latency observations with the unshaped baseline. Annotate competing workload, any interruption and any method change. Use the same test service throughout the comparison unless a separate check explains why another endpoint is needed.\nRetain the sequence of settings and observations so a second administrator can identify the selected tradeoff. Include a return to the previous setting if the pilot becomes unacceptable, then verify the restored configuration. Record the application owner’s observed acceptance separately. Reopen the tuning decision after a circuit-rate or traffic-path change rather than assuming the earlier values remain suitable.\nOfficial references\n\nOPNsense — Fighting Bufferbloat with FQ_CoDel — official product documentation; confirm the installed release and configuration.\n\nSource review completed October 28, 2026. Recheck the official documentation and deployment-specific applicability before a production change.", "datePublished": "2026-10-29T00:10:11+00:00", "dateModified": "2026-10-29T00:10:34+00:00", "mainEntityOfPage": { "@id": "https://update.dsesecurity.com/updates/tune-opnsense-fq-codel-bandwidth-against-latency-under-load/" }, "inLanguage": "en-US", "isAccessibleForFree": true, "author": { "@type": "Organization", "name": "DSE Security Editorial Team", "url": "https://update.dsesecurity.com/#editorial-team" }, "publisher": { "@id": "https://dsesecurity.com/#organization" }, "image": { "@type": "ImageObject", "@id": "https://update.dsesecurity.com/updates/tune-opnsense-fq-codel-bandwidth-against-latency-under-load/#primaryimage", "url": "https://update.dsesecurity.com/assets/editorial/network-infrastructure-social-v2.jpg?v=1.8.20", "contentUrl": "https://update.dsesecurity.com/assets/editorial/network-infrastructure-social-v2.jpg?v=1.8.20", "width": 1200, "height": 630, "caption": "Tune OPNsense FQ_CoDel bandwidth against latency under load" }, "articleSection": [ "IT", "Networks & Infrastructure" ], "keywords": [ "IT", "Networks & Infrastructure", "Guide", "Advisory priority" ], "genre": "Guide", "about": [ { "@type": "Thing", "name": "IT", "url": "https://update.dsesecurity.com/topic/it/" }, { "@type": "Thing", "name": "Networks & Infrastructure", "url": "https://update.dsesecurity.com/topic/networks-infrastructure/" } ], "wordCount": 576, "timeRequired": "PT3M", "publishingPrinciples": "https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/", "usageInfo": "https://update.dsesecurity.com/usage/", "copyrightHolder": { "@id": "https://dsesecurity.com/#organization" }, "copyrightNotice": "Copyright © 2026 Detection Systems & Engineering. All rights reserved.", "citation": { "@type": "CreativeWork", "name": "OPNsense — Fighting Bufferbloat with FQ_CoDel", "url": "https://docs.opnsense.org/manual/how-tos/shaper_bufferbloat.html" } } ] } }