Field Value
Manuscript version 1.0.0
Status Public technical manuscript
Publication date 2026-07-02
Canonical URL https://octocore.ai/research/mulan-sqm-qos-evaluation/
Router under test Mulan, OpenWrt One
Firmware family OpenWrt 24.10.x

0.1 Revision History

Version Date Author Changes
1.0.0 2026-07-02 Octocore Autonomous Systems, LLC Initial public manuscript summarizing controlled WAN SQM, flow-offload, and 5 GHz radio SQM testing on Mulan.

0.2 Abstract

Smart Queue Management (SQM) is a standard remedy for bufferbloat, but its benefit depends on where the real bottleneck is, whether the router can shape at the required rate, and whether the measured traffic path exercises the same forwarding behavior used by household clients. We evaluated several operating states for Mulan, an OpenWrt One residential edge router on an asymmetric 1 Gbit/s AT&T fiber service: a throughput-oriented state with WAN SQM disabled and software/hardware flow offload enabled (G3), a WAN CAKE/SQM state at 850 Mbit/s symmetric shaping with offload disabled (G2-A), and a 5 GHz radio SQM state layered onto G3. The strongest WAN test used a temporary high-capacity GCP iperf3 endpoint and router-side passive CPU monitoring. G3 delivered approximately line-rate throughput from Mulan to GCP (1032.380) Mbit/s and high reverse throughput (940.710) Mbit/s, while G2-A reduced receiver throughput to 760.173 and 693.501 Mbit/s, respectively. G2-A also produced repeated zero-idle router CPU samples without a meaningful loaded-ping improvement. On the 5 GHz radio path, radio SQM worsened Data/Envy bufferbloat scores and produced a mixed JARVIS result: improved upload-loaded latency but reduced JARVIS-to-Mulan throughput by about 100 Mbit/s. We conclude that Mulan’s current default should be G3 throughput mode: WAN SQM off, per-radio SQM off, and firewall software/hardware flow offload on. SQM should remain installed and scripted as a reversible test profile, with a future hardwired LAN-client experiment reserved for the remaining forwarding-path question.

0.3 Introduction

Bufferbloat occurs when excess queueing delay accumulates during saturation. SQM systems such as CAKE and fq_codel address this by pacing traffic and applying fair queueing at a deliberately controlled bottleneck. The practical question is not whether SQM is useful in general. The practical question is whether a specific SQM placement and rate improves the measured path enough to justify its throughput and CPU cost on the specific router.

Mulan had several plausible tuning choices. One earlier posture used WAN CAKE on eth0 as the primary bottleneck shaper. A later posture disabled WAN SQM, enabled hardware flow offload, and left SQM attached to Wi-Fi AP interfaces. That made the network fast, but it left open whether latency was being protected in the right place. The evaluation described here was designed to separate three mechanisms that are often conflated:

  1. WAN SQM, which deliberately shapes the ISP-facing link;

  2. firewall software/hardware flow offload, which accelerates eligible forwarded flows;

  3. per-radio SQM, which shapes traffic at Wi-Fi AP interfaces rather than at the WAN bottleneck.

The study focused on a defensible operating recommendation for Mulan rather than an exhaustive factorial design. The criteria were throughput, loaded latency, packet loss, and router CPU pressure.

0.4 Materials and Methods

0.4.1 Router and Network Context

The router under test was Mulan, an OpenWrt One running OpenWrt 24.10.x. The WAN service was an AT&T fiber connection sold as an asymmetric 1 Gbit/s service. The ISP gateway was a Nokia BGW320 operating with IP Passthrough to Mulan/KARLA infrastructure. The built-in BGW320 speed test typically reported approximately 1.2 Gbit/s upstream and around 48 ms average latency during the period of this study, with a known downstream reporting anomaly that returned zero downstream throughput.

The tested Mulan states were:

State WAN_SQM Per_radio_SQM Flow_offload Intended_question
G3 throughput off off software and hardware on Fast-path throughput and loaded latency without explicit shaping
G2-A WAN SQM CAKE on eth0 and ifb4eth0 at 850/850 Mbit/s off software and hardware off WAN bottleneck control with CAKE at a high shaper rate
G3 plus 5 GHz radio SQM off 5 GHz phy1-ap0 enabled software and hardware on Whether radio-local shaping improves Wi-Fi-client bufferbloat

0.4.2 WAN Test Endpoint

KARLA/HUB VPN testing was useful for topology validation, but it was not strong enough to approach Mulan’s candidate WAN shaper rate. For the final WAN comparison, a temporary GCP c3-standard-8 instance in us-east1-b was created as a public iperf3 endpoint. The helper restricted TCP/5201 ingress to Mulan’s current public egress address, installed a systemd-managed iperf3 server, and deleted the VM and firewall rule after the test. Follow-up GCP describe checks confirmed that no persistent GCP test endpoint remained.

Both G3 and G2-A WAN tests used identical iperf3 parameters:

Parameter Value
iperf3 duration per direction 45 seconds
Streams 4
Omit/warmup 5 seconds
Passive Mulan monitor duration 150 seconds
Passive Mulan monitor interval 2 seconds
Idle ping count before and after 15
Ping targets GCP endpoint and 1.1.1.1

0.4.3 Wi-Fi Client Tests

Two 5 GHz Wi-Fi client paths were tested. Data’s reachable VPN name resolved to the Envy host used for Cloudflare loaded-latency testing. JARVIS used a faster modern Wi-Fi adapter and was tested with local iperf3 to isolate Wi-Fi-to-Mulan behavior from Internet server selection effects. WAN SQM remained disabled and firewall software/hardware flow offload remained enabled during the Wi-Fi radio SQM tests.

The Data/Envy test used a Cloudflare loaded-latency tool bound to the 5 GHz Wi-Fi interface with IPv4 forced. Each condition used three trials, 15 s download, 15 s upload, 8 s idle latency, six concurrent flows, 250 ms probes, and a 2000 ms probe timeout.

The JARVIS test started a temporary iperf3 server on Mulan bound to 192.168.5.1, ran JARVIS-to- Mulan and reverse tests with four streams for 30 s per direction, ran concurrent pings to Mulan and 1.1.1.1, passively monitored Mulan, and removed the temporary listener.

0.4.4 Outcome Measures

The primary outcomes were receiver throughput, loaded-ping behavior, packet loss, router CPU/softirq pressure, and observed queue discipline behavior. Throughput-only results were treated as insufficient because a configuration can be fast while still creating unusable latency under load. Likewise, a latency improvement was not considered sufficient if it required excessive throughput loss or saturated the router CPU.

0.5 Results and Discussion

0.5.1 WAN G3 Versus G2-A Throughput

State Direction Receiver_Mbps Sender_Mbps Retransmits Router_or_Host_CPU_percent
G3 throughput Mulan to GCP 1032.380 1032.731 797 10.719
G3 throughput GCP to Mulan reverse 940.710 940.765 1438 30.113
G2-A WAN SQM Mulan to GCP 760.173 760.043 10 8.090
G2-A WAN SQM GCP to Mulan reverse 693.501 693.770 1416 53.426

G3 delivered approximately 36% more receiver throughput than G2-A in both WAN directions. The absolute difference was 272.207 Mbit/s from Mulan to GCP and 247.209 Mbit/s in the reverse direction. This is the expected cost of placing an 850 Mbit/s shaper below a service that can exceed that rate, but the cost is only justified if loaded latency improves meaningfully.

0.5.2 WAN Router CPU and Loaded Ping

State Highest_sampled_router_busy_percent Zero_idle_samples High_water_summary
G3 throughput 87 0 73% usr, 13% sys, 13% idle
G2-A WAN SQM 100 4 21% usr, 34% sys, 0% idle, 4% irq, 39% sirq
State Phase Endpoint_avg_ms OneOneOneOne_avg_ms
G3 throughput idle before 22.709 14.388
G3 throughput upload loaded 24.942 16.019
G3 throughput reverse loaded 23.776 13.106
G3 throughput idle after 23.839 12.977
G2-A WAN SQM idle before 23.157 12.881
G2-A WAN SQM upload loaded 26.227 16.454
G2-A WAN SQM reverse loaded 25.032 13.935
G2-A WAN SQM idle after 23.333 12.594

G2-A engaged CAKE and recorded drops and overlimits, so the shaper was active. However, its loaded ping advantage was negligible in this Mulan-origin WAN test. Endpoint average ping during upload load was 24.942 ms for G3 and 26.227 ms for G2-A. Reverse-loaded endpoint average ping was 23.776 ms for G3 and 25.032 ms for G2-A. The 1.1.1.1 comparison was similarly close.

The CPU evidence points the other way. G2-A produced four zero-idle passive router samples and a high-water line with 39% softirq, while G3 produced no zero-idle samples. For this test path, WAN CAKE at 850 Mbit/s reduced throughput and increased router pressure without improving loaded latency.

This test does not fully answer the household forwarding case, because traffic originated by Mulan itself does not exercise LAN-client forwarding, NAT, Wi-Fi airtime, or flowtable behavior in the same way a wired LAN client would. It does answer the narrower question that was testable at the time: Mulan-origin public Internet traffic did not benefit from G2-A.

0.5.3 Data/Envy 5 GHz Radio SQM

State Download_Mbps Upload_Mbps Idle_median_ms Download_loaded_median_ms Upload_loaded_median_ms Bufferbloat_delta_ms Grades
5 GHz radio SQM off 141.341 206.859 39.604 58.381 55.991 20.462 A,A,A
5 GHz radio SQM on 135.111 204.303 35.158 67.295 57.128 32.137 A,B,B

For Data/Envy, 5 GHz radio SQM did not improve bufferbloat. It slightly reduced throughput and worsened the mean bufferbloat delta from 20.462 ms to 32.137 ms. Trial grades moved from A,A,A with radio SQM off to A,B,B with radio SQM on. This result argues against using per-radio SQM as a default household policy.

0.5.4 JARVIS 5 GHz Radio SQM

State Direction Receiver_Mbps Sender_Mbps Retransmits
5 GHz radio SQM off JARVIS to Mulan 275.641 276.048 0
5 GHz radio SQM off Mulan to JARVIS reverse 524.777 524.177 40
5 GHz radio SQM on JARVIS to Mulan 175.481 176.990 2
5 GHz radio SQM on Mulan to JARVIS reverse 531.446 531.417 8
State Load_phase Target Loss_percent Avg_ms
5 GHz radio SQM off JARVIS upload Mulan 192.168.5.1 3 320.537
5 GHz radio SQM off JARVIS upload 1.1.1.1 0 353.980
5 GHz radio SQM off Mulan reverse Mulan 192.168.5.1 0 20.541
5 GHz radio SQM off Mulan reverse 1.1.1.1 0 36.161
5 GHz radio SQM on JARVIS upload Mulan 192.168.5.1 0 205.416
5 GHz radio SQM on JARVIS upload 1.1.1.1 0 218.020
5 GHz radio SQM on Mulan reverse Mulan 192.168.5.1 0 21.572
5 GHz radio SQM on Mulan reverse 1.1.1.1 0 30.733

JARVIS showed a mixed result. Radio SQM improved the severe upload-loaded local latency problem: average ping to Mulan during JARVIS upload fell from 320.537 ms to 205.416 ms, and packet loss fell from 3% to 0%. However, JARVIS-to-Mulan throughput fell from 275.641 Mbit/s to 175.481 Mbit/s. The reverse Mulan-to-JARVIS throughput and latency were essentially unchanged.

That is not a clean default-policy win. The profile improved one directional symptom but still left high upload-loaded latency and imposed a large throughput cost. It also increased passive Mulan CPU pressure, with the high-water router busy sample rising from 69% to 88%.

0.5.5 Operating Recommendation

The current evidence favors G3 throughput mode as Mulan’s default:

  1. WAN SQM off;

  2. per-radio SQM off;

  3. firewall software and hardware flow offload on;

  4. SQM left installed and configured only as a reversible test profile.

This conclusion is intentionally narrower than “SQM is bad.” The conclusion is that the tested SQM placements and rates did not provide enough benefit on Mulan’s current measured paths to justify their throughput and CPU costs as defaults. A future wired LAN-client experiment could still change the WAN recommendation if it shows that LAN forwarding creates loaded latency that G3 does not control and WAN CAKE does.

0.6 Conclusions

The tested data do not support default SQM on Mulan at this time. In the strongest WAN comparison, G3 reached roughly line-rate behavior and kept loaded ping close to idle, while G2-A reduced throughput, increased router CPU pressure, and did not improve loaded ping. On Wi-Fi, per-radio SQM worsened Data/Envy bufferbloat and produced only a partial JARVIS upload-latency improvement at a large throughput cost.

The defensible operating state is therefore G3 throughput mode: WAN SQM disabled, per-radio SQM disabled, and firewall software/hardware flow offload enabled. The remaining decision-quality gap is a future hardwired LAN-client test against a high-capacity endpoint. That test will exercise the household forwarding path that Mulan-origin iperf3 cannot.

0.7 Limitations

This was a pragmatic field evaluation, not a randomized laboratory experiment. The WAN test used Mulan-origin traffic because a hardwired LAN client was not available at the time. Cloudflare and public Internet measurements can vary with time, server selection, and upstream path behavior. The Wi-Fi results represent the tested clients and channel conditions, not every possible household device. The conclusion should be revisited when a hardwired desktop server is available.

0.8 Source Artifacts

The manuscript is derived from internal governed-session artifacts. Raw packet paths, temporary cloud resource details, and private diagnostic files are intentionally not published here.

Handle Role
20260702_014152.report.gcp_endpoint_g3_vs_g2a_comparison.md WAN G3 versus G2-A throughput, latency, and router CPU comparison
20260702_023800.report.wifi_phy_sqm_data_jarvis_ab.md 5 GHz radio SQM A/B results for Data/Envy and JARVIS
20260630_160558.plan.controlled_sqm_qos_tuning_matrix.md Pre-test design matrix and measurement requirements
20260630_125235.report.sqm_qos_truth_model.md Mechanism model for SQM, CAKE, classic QoS, DSCP, and flow offload

0.9 References

  1. OpenWrt Project. “SQM (Smart Queue Management).” OpenWrt documentation.

  2. OpenWrt Project. “Flow offloading.” OpenWrt documentation.

  3. Bufferbloat Project. “Smart Queue Management.” Bufferbloat documentation.

  4. Hoeiland-Joergensen, T., McKenney, P. E., Taht, D., Gettys, J., and Dumazet, E. “The Flow Queue CoDel Packet Scheduler and Active Queue Management Algorithm.” IETF RFC 8290, 2018.

  5. Morton, J. and Taht, D. “The CAKE shaper.” Common Applications Kept Enhanced documentation and Linux traffic-control implementation notes.

  6. iperf3 project. “iperf3: A TCP, UDP, and SCTP network bandwidth measurement tool.”

  7. Cloudflare. “Speed test and network quality measurement tooling.”