mt76 速率控制：为什么客户端会被钉在 MCS0（以及如何证明）

2026-10-11 · 约 3 分钟

如果一台 OpenWrt + mt76 的 AP 只对某一个客户端发 MCS0，而其他客户端一切正常，那不是错觉—— 而且通常不是信号问题。下面是这次的实测调查。

1. 先看对计数器

iw dev <ap> station dump | grep -E "Station|tx bitrate|rx bitrate|tx failed|tx retries|expected"

还要用一次廉价的内网传输确认方向，并在两端统计字节数（见第 3 节）。 如果 AP 发出的字节远多于客户端收到的，那是重传风暴；如果两边差不多，那只是空口空闲。

2. mt76 的速率控制在哪里

cat /sys/kernel/debug/ieee80211/phy*/rate_ctrl_alg      # -> hw/driver
cat /sys/kernel/debug/ieee80211/phy*/hwflags            # -> HAS_RATE_CONTROL

hw/driver 加上 HAS_RATE_CONTROL 意味着速率由固件/SoC 决定——mac80211 的软件速率控制（minstrel） 并不负责。所以"换个速率算法"不是选项；你只能间接影响它。

实践中有两个 debugfs 开关值得关注：

cat /sys/kernel/debug/ieee80211/phy*/mt76/vow_atf      # 固件空口公平性，默认 1
cat /sys/kernel/debug/ieee80211/phy*/mt76/aql_enable   # 空口队列上限

3. 定位到缺陷的那次测量

同一客户端、同一时段，只改 vow_atf（E 级证据——原始抓包与产生它们的脚本已公开 ^{[1] [2]}）。空闲 60 秒，然后连续 6 次 6 秒的内网下载：

塌陷状态下的字节对账：12 秒传输，AP 发出 12.87MB，客户端收到 12.4MB。 几乎没有重传浪费——速率很低、信道大部分空闲。这就排除了"客户端收不到"，指向速率选择。

4. 塌陷到底是什么造成的

两个互相独立的触发条件，在 MT7986 + mt76 上都能复现：

1. 客户端空闲/省电行为：约 1 秒空闲就足以让 AP 的发送速率掉到 MCS0 1SS。 在 vow_atf=1 下，即使随后持续满载，它也一直待在那里。
2. 窄带客户端在宽带 BSS 里：只支持 40MHz 的客户端放进 80MHz BSS 会周期性塌陷，与 ATF 无关。 用它的原生带宽（40MHz BSS）运行则稳定在 380–420Mbps。

5. 该怎么做

# 1) 关掉那个阻止速率恢复的固件特性（并持久化）
echo 0 > /sys/kernel/debug/ieee80211/phy*/mt76/vow_atf

# 2) 如果客户端只支持 40MHz，就让射频宽度与它一致
sh /usr/bin/wifi-htmode HE40      # CSI 分辨率下降；客户端恢复可用

# 3) 最后一招：强制一次全新关联（重置速率状态）
iw dev <ap> station del <client-mac>

第 1 步持久化很重要：debugfs 的值会在驱动重载后丢失。本项目工具箱提供了开机初始化脚本与 每分钟重放的 watchdog（scripts/mt76-wifi-tune、scripts/csi-watchdog.sh）。

6. 不该下的结论

• 别相信单次 tx bitrate 采样（它是最后速率，不是均值）；
• 没做方向测试就别怪客户端（本例上行物理层 600Mbps、实测 188Mbps，完全正常）；
• 别用公网镜像做测试：宽带本身的波动会伪装成 Wi-Fi 行为。

相关：80MHz vs 40MHz · OpenWrt 空闲后变慢 · 路由器 CSI 复现