3、吞吐量监控原理归纳总结
吞吐量监控，说白了就是搞清楚你的SDIO接口到底跑了多少有效数据。我刚开始做SDIO调试时，总盯着时钟频率看，以为频率高吞吐肯定高——结果被打脸了。后来我明白，时钟只是上限，实际吞吐受命令开销、CRC校验、总线占用率、主机响应延迟等多方面影响。这一节，我把吞吐量监控的核心原理掰开揉碎，讲清楚。
吞吐量监控的核心指标
衡量SDIO吞吐，不能只看一个数。你得同时盯几个关键指标，才能定位瓶颈。我习惯把它们分成三类：
| 指标类别 | 指标名称 | 描述 |
|---|---|---|
| 速率类 | 数据吞吐率（MB/s） | 单位时间内传输的有效数据量，排除命令、CRC、空闲周期 |
| 时钟频率（MHz） | SD_CLK的实际工作频率，受分频系数和卡支持上限约束 | |
| 延迟类 | 命令响应时间（μs） | 从主机发出命令到收到卡响应的延迟 |
| 数据块间隔（μs） | 相邻数据块之间的总线空闲时间 | |
| 利用率类 | 总线占用率（%） | 有效数据传输时间占总时间的比例 |
| 重传率（%） | CRC失败导致的重传块数占总块数比例 |
我记得有个项目，客户反馈WiFi吞吐只有标称值的60%。我抓了命令响应时间，发现卡端响应居然波动到800μs以上——正常应该在50μs以内。后来查到是卡侧电源不稳，加上去耦电容就恢复了。你看，只看吞吐率根本不知道问题出在哪。
监控原理与采样方法
想拿到上面那些指标，不能靠猜。实际调试中，我用三种方法获取原始数据：
- 硬件计数器：SDIO控制器内部通常有数据块计数器和循环冗余校验（CRC）错误计数器。你只需读取寄存器，就能拿到原始块数和错误块数。
- DMA传输统计：如果使用DMA模式，可以在DMA完成中断里记录总字节数和传输时间。注意，这里的时间要扣除中断处理开销。
- 软件时间戳：在驱动层的入口和出口打时间戳，计算命令+数据的总耗时。这个方法最简单，但精度受系统调度影响，适合粗粒度分析。
我建议组合使用：硬件计数器做基准，软件时间戳做趋势分析。我曾经在一个Linux平台上，用getnstimeofday()在mmc_request开始和结束时打点，然后除以块数算出平均每块耗时——结果发现某个批处理请求的时间特别长，追下去才发现是DMA描述符链的尾指针配置错了。
吞吐量计算的数学模型
实际吞吐率的公式并不复杂，但要注意隐藏的开销：
实际吞吐率 (MB/s) = 有效数据字节数 / 总传输时间
其中：
- 有效数据字节数 = 成功传输的数据块数 × 块大小（通常512字节）
- 总传输时间 = 命令发出到最后一个数据块CRC完成的时间这里容易踩坑：总传输时间必须包含命令、响应、块间隙、CRC校验和总线空闲时间。我见过有人只算数据块本身的传输时间，结果算出来的吞吐比标称还高——这不是吹牛，是算错了。
举个例子：SDIO在4位模式、50MHz时钟下，理论峰值是200Mbps（25MB/s）。但如果你连续写100个512字节块，每个块之间有2个时钟周期的间隙，加上命令和响应占用约50个时钟周期，实际吞吐可能只有18～20MB/s。这20%的差距，就是命令和间隙吃掉的。
常见瓶颈与排查思路
当你发现吞吐率低于预期时，别急着怀疑卡。我按出现频率排了个优先级：
- 时钟频率设错：检查分频系数，确认SD_CLK实际输出。用示波器量一下最直观。
- 总线占用率低：如果命令响应时间太长，或者块间隙太大，总线利用率会掉到50%以下。抓命令响应时间，看是否超过100μs。
- CRC重传：重传率超过1%就要警惕。检查信号完整性，特别是SDIO_DAT线和CLK的边沿对齐。
- 主机端驱动效率：轮询模式比中断模式开销大，中断模式下中断频繁也会吃掉CPU。我建议用DMA+环形缓冲。
- 卡端电源波动：卡供电纹波超过5%时，内部逻辑可能降频或产生CRC错误。加一级LC滤波。
下面这张流程图概括了整个吞吐量监控的思路。从原始数据采集到形成可决策的报告，每个环节都可能引入误差，需要根据实际情况调整采样粒度。
嗯，这张图看起来结构清晰吧？实际调试中，我经常在“数据预处理”这一步发现数据异常——比如硬件计数器溢出了，或者软件时间戳被中断上下文冲掉了。记住，原始数据的质量决定了分析结果的可靠性。