原帖 ｜ 🌶 ｜ 2026-02-01 18:39 ｜ 👍4 ｜ 阅读约1
问题模型：wifi延迟速率优化出现各类优化方法
项目背景：
回溯一下前文的研究结论@：实际查阅资料可知在逻辑调度这一层，为啥会触发这个20s周期扫描是因为评分机制，wifi信号不佳导致评分低导致扫描寻求更好的wifi源，最终将问题可以导向到底层wifi模块通信的问题 驱动层/硬件层通信不佳，但是可以调整扫描周期间隔来缓解延迟发生率，可达到平均300ms以下的延迟，较该手段前500ms以上大大缓解，等后续和供应商继续研究
现在继续硬件/驱动层的研究
问题分析定位：
将上次我们找到的framework层的参数调整之后，基于这一优化方法，我们的ping延迟包不会再出现500ms以上的延迟，但是平均延迟依旧是50~200之间，于是我们开始研究驱动代码，通过翻阅供应商提供的模块文档和介绍可知,proc路径下存在驱动厂商提供的wifi参数接口，关于信号类问题的研究，我的思路是：信号发生源-信号速率-信号接收处理这三个层次考虑问题，上文的修改主要是基于信号接收处理方面做的优化，这里我们先验证信号发生源和信号速率
实验设计：
，通过cat /proc/net/xxx/wlan0/rx_signal ，我们可以清楚的看到信号质量和信号速率等相关参数，这里我们可以敏锐的看到信号质量rssi:-45是非常好的，因为我是开手机热点进行测试，距离机器非常近，但是有一个异常点就是在质量如此好的情况下，wifi模组选择速率竟然是最低的CCK_1M，由此我们又引出两个驱动内部的机制，速率自适应算法RA和抗干扰DOM算法，这两个的决策影响了wifi模组对速率模式的选择，去查看算法修改底层查明原因为何选择？这样对整体流程更为明晰，但时间成本过高，那么不如我们直接将速率模式改成高速率看看网速延迟是否降低再来分析这个选择更具性价比，说干就干：去到hal层进行修改
/odm.c
pRaInfo->RateMask
RateAdaptive.c
hal_com_reg.h
将Rxraye参数剔除CCK_1M
然后烧录测试，果不其然，速率大大提升
问题梳理：
之前想的：
现在手段估计就这四个：
2.将模块的节能模式关闭掉验证看 CONFIG_POWER_SAVING = n [驱动底层]
这个实际上是提高模块功率，能让他叫的距离更远，对速率影响不大
3.提高扫描阈值，避免频繁扫描
这个是在Andrio决策修改，对wifi延迟优化高
4.硬件信道锁定，驱动定死HT20模式，避免其他信道干扰
这个没用
5.修改驱动源码/设备树对照配置参数
这个没用
实测发现效果不大，主要是深入研究了wifi驱动源码和框架来进行的问题分析和优化，这里给出梳理：
四层垂直架构（数据流向）
OS 接口层 (OS Interface)：
对接 Linux 网络协议栈。它不关心信号，只关心“包”。我用的proc 接口就在这一层实现。
逻辑控制层 (MAC Control)：
驱动的核心大脑。负责加解密、帧重组，以及你最关心的速率选择算法（Rate Adaptive）。它决定这一刻是用 1M 还是 MCS7。
硬件抽象层 (HAL)：
它是翻译官。把逻辑层定下的“速率索引”转换成芯片寄存器能懂的 0xXXXXXXXX 原始数据。
物理层 (PHY/RF)：
最底层。执行具体的射频发射、功率控制（Tx Power）和信道监听。
收获：
寥寥几句，说的精简，但是弯路走了不少，也算是填了之前的坑，但最终还是梳理出了一个解决wifi延迟问题的路线，这其中其实最重要的还是能了解wifi驱动框架，然后研究驱动源码，最后定位修改就相当简单了，此次主要是修改了HAL层进行了速率优化，但是core逻辑控制层RA算法那块还没仔细，先确认确实是这个原因引起再去研究，这是目前的进度，这里先埋个伏笔，关于wifi驱动源码的研究和阅读方法等后面得空再出，然后其实隐隐约约我的解决问题通用模型慢慢有雏形了，他就像一个大框架，对于具体问题只需要将节点的具体技术套进去就可以解决，这个等积累的各类优化debug问题渐多可以考虑出一个详细描述
当然了，最后的优化效果也相当给力，达到平均延时30ms,直追手机，也算小成就一件./
相关笔记
- 📁 返回本主题 MOC
- 问题模型（wifi驱动ping
- 问题模型（wifi驱动ping
- 问题模型（防跌落立体视觉相机掉
- 蓝牙软件工程师（应届生7-9k ： 1-2 年经验10-15k）13薪
- 机器人通信EtherCAT与CAN
- 老师，usb协议栈与蓝牙协议栈的职业发展前景对比，usb差很多