The GL.iNet Flint 3 (BE9300), powered by the Qualcomm IPQ53xx platform, is a powerful Wi-Fi 6E router that supports advanced OpenWRT features. One of the most discussed areas of performance tuning on OpenWRT is Quality of Service (QoS), particularly the distinction between software-based Smart Queue Management (SQM) and hardware-accelerated QoS.
SQM vs Hardware-Accelerated QoS
Smart Queue Management (SQM)
SQM is a software-based traffic management system designed to reduce latency under load by controlling how packets are queued and prioritized. It commonly uses queuing disciplines like cake
or fq_codel
.
Pros:
- Excellent for reducing bufferbloat.
- Offers precise control over upload/download bandwidth.
- Ideal for VoIP, gaming, and video conferencing.
Cons:
- CPU-intensive; not hardware-accelerated.
- May reduce throughput on gigabit-class connections (CPU-bound).
Hardware-Accelerated QoS (NSS, FastPath)
On Qualcomm platforms like the IPQ53xx, hardware acceleration refers to NSS (Network SubSystem) engines that offload routing, NAT, and QoS processing from the CPU. This can dramatically improve performance and throughput.
Pros:
- Much higher throughput (multi-gigabit potential).
- Lower CPU usage under load.
- Better for large households with many devices.
Cons:
- Not supported in upstream OpenWRT (as of 23.05-SNAPSHOT).
- Requires proprietary drivers and custom firmware builds.
- Limited visibility/control compared to SQM.
Flint 3 and OpenWRT 23.05-SNAPSHOT
If you’re running a snapshot of OpenWRT 23.05 (as you are), then:
- SQM is fully supported.
- Hardware-accelerated QoS (NSS) is not included.
You can enable basic software flow offloading but it is not the same as full hardware NSS offloading.
Enabling SQM on OpenWRT
- Install SQM:
opkg update
opkg install sqm-scripts luci-app-sqm
- Go to LuCI:
http://<router-ip>/cgi-bin/luci/admin/network/sqm
- Configure:
- Select your WAN interface (e.g.,
eth0.2
orwan
) - Set bandwidth (a few percent below your ISP’s max speeds)
- Choose
cake
+piece_of_cake.qos
- Enable and save
- Optional CLI configuration:
uci set sqm.@queue[0].enabled='1'
uci commit sqm
/etc/init.d/sqm restart
Enabling Software Flow Offloading
- Go to LuCI:
Network > Firewall > Settings
- Scroll to Software flow offloading and enable it
- Save & Apply
⚠️ Hardware flow offloading may appear as an option but will not function correctly without proprietary support (not in upstream).
Performance Summary
Feature | SQM (Cake/FQ-CoDel) | Hardware QoS (NSS/FastPath) |
---|---|---|
Max Speed | ~300–800 Mbps (CPU-bound) | >1 Gbps (offloaded) |
Latency Under Load | Excellent | Varies |
Bufferbloat Mitigation | Best in class | Limited |
CPU Usage | High | Low |
Configurability | High (manual tuning) | Low (black-box nature) |
Availability in 23.05 | ✅ Yes | ❌ No |
Conclusion
If your priority is low latency and bufferbloat control, SQM is your best tool on OpenWRT for the Flint 3. However, it trades off raw throughput due to its CPU-bound nature. For those seeking maximum throughput with many devices, hardware-accelerated QoS (when available in the future or via custom firmware) will be ideal.
Until upstream support for NSS offloading matures on IPQ53xx, OpenWRT users on the Flint 3 should stick with SQM for optimal control and performance balance.