Wi-Fi省电与DTIM：诊断下行命令延迟

先观察空闲后的第一条命令

设备在连续交互时很快，安静一段时间后的第一条命令却明显变慢，可能是在等待无线唤醒机会。但这只是有用假设，不能直接当作诊断结论。应记录命令产生、进入AP侧网络、设备接收回调和业务完成的时间，再结合上一次流量距今多久。本文聚焦站点省电与下行缓存，参考Linux 6.12 mac80211及观测到的Nordic nRF Connect SDK 3.4.99开发版文档，不把每种延迟都归因于DTIM，也没有报告板卡电流或时延实测。

区分信标、DTIM和客户端唤醒策略

信标携带时序与流量指示，AP的DTIM周期与缓冲的组地址流量交付节奏有关；站点监听策略和具体省电机制同样重要。Linux 6.12 mac80211说明暴露AP的DTIM参数，并说明取得信标中的相关值后才能启用其省电行为。但这不代表所有客户端的每个单播包都必须等到DTIM。传统取包、WMM省电、固件策略及其他机制可能不同，应先确定真正启用的模式，再按对应供应商文档解释接收机会，不能用一个周期公式代替实现调查。

供应商行为必须保留供应商边界

Nordic站点省电文档描述其Wi-Fi设备的DTIM、监听间隔和TWT模式。在该实现所述的DTIM模式下，下行接收跟随DTIM唤醒；较长监听间隔可能错过组地址帧。这来自开发文档构建，不证明同名接口或默认值存在于你的正式SDK。应用说明前，要记录实际SDK标签、无线固件和AP能力。设备标有Wi-Fi 6，也不证明TWT已经建立。应分别保留请求配置、接口接受以及抓包或支持的无线诊断所观察到的实际唤醒行为。

时序模型不能变成未经验证的上界

作为纯概念例子，假设信标间隔100毫秒，DTIM周期为三个信标，则相关节奏为300毫秒。这个乘法描述调度机会，不是命令延迟上限。包到达相位、竞争、丢包、重试、AP缓存及应用调度都可能增加等待。刚错过唤醒机会的命令，可能比恰好提前到达的命令等得更久。因此测试应在空闲后使用不同偏移发命令，不要一直按单一同步周期发送。缩短DTIM周期不能直接推导为端到端延迟同比例缩短，更不能作为未经测量的服务承诺。

单播和组播实验必须分开

直接单播命令、组播发现请求以及依赖广播的配网步骤应分别测试。设备可能稳定接收单播，却因组地址交付与睡眠策略的相互作用而在发现列表中消失。记录目的地址类型、负载长度，以及是否先有别的流量唤醒设备。不要只用连续ping当作对照，探测本身可能破坏引发故障的空闲条件。至少比较静默基线、空闲后的孤立命令和连续突发。如果设备接收时间已经很早，实际业务动作却晚，应先查看任务调度和工作队列，而不是立即修改AP参数。

把电流与报文放在同一时间线上

使用合适的电流测量装置和独立抓包，在可行时用可观察标记对齐两者。记录采样率、测量串入影响、供电边界，以及调试探针是否改变睡眠。应对代表性工作周期积分得到能量，而不是只展示最低瞬时电流。在相同硬件、固件、AP和负载下，对比开关省电作为受控诊断，但关闭省电不自动成为出货建议。如果工具无法直接观察无线唤醒状态，应把结论标成由电流及报文时序推断。上述是建议测量步骤，并不意味着已取得某个节能百分比或电池寿命。

有计划地改变AP验证矩阵

保持无线条件和安全模式不变，每次只调整一个受支持AP参数，例如DTIM节奏，再恢复基线。针对产品矩阵中的实际AP型号验证每种支持的客户端睡眠模式，包括空闲断开策略。客户端普通省电设置通常不能直接指定AP的DTIM配置。还应检查较长监听间隔是否牺牲必要组播行为，以及业务保活是否抵消预期节能。冷启动关联、稳定空闲、背景流量和失联恢复要分开记录。复现需要调整生产网络时，应与获授权管理员协调并记录影响范围，不能把实验建议当作现场直接操作指令。

按业务要求选择取舍

验收指标应包含对应空闲时长后的首命令延迟、连续交互延迟、组播发现可靠性，以及真实运行周期能量。说明百分位计算方法并保留失败样本，没有放之四海而皆准的数值目标。可容忍延迟轮询的电池传感器，与要求及时执行的控制器，即使用同一无线芯片也可能需要不同策略。若SDK支持，可考虑在有界交互期间临时进入响应模式，但必须验证进入、退出和故障恢复。最后交付版本明确的配置与功耗时延取舍说明；只有能解释实际时间线时，DTIM分析才真正完成。