4. 性能瓶颈分析框架：吞吐量、延迟、CPU占用率、功耗四大维度及其权衡
做USB OTG性能调优，最怕什么？
很多人拿到一个高速设备，上来就调缓冲区大小，或者盲目改DMA配置。结果呢？要么延迟降了但吞吐量崩了，要么CPU占用率飙升导致系统卡死。我见过太多这样的案例了——有一次客户抱怨某UVC摄像头丢帧严重，我一看代码，他们把中断频率提到最高，CPU全耗在中断处理上，本来应该做图像传输的时间全浪费了。
所以这一章，我想跟你聊聊性能调优必须搞清楚的四个维度：吞吐量、延迟、CPU占用率、功耗。这四个东西是互相耦合的，牵一发而动全身。我们先拆开看，再讲怎么权衡。
4.1 四大维度拆解
先给个总览表，我习惯把这四个维度比作一个跷跷板的四个角——你动一个，其他三个都会跟着晃。
| 维度 | 核心指标 | 典型瓶颈 | 我见过最坑的情况 |
|---|---|---|---|
| 吞吐量 | MB/s | 总线带宽、DMA速率、USB帧间隔 | 某设备宣称USB 3.0，实际只有不到200MB/s，查了半天是端点缓冲区设太小 |
| 延迟 | 微秒/毫秒 | 中断响应、调度延迟、传输排队 | 某工业相机实时性要求1ms以内，结果USB中断优先级设太低，被网卡抢了CPU |
| CPU占用率 | % | 中断次数、数据拷贝、协议栈处理 | 某调试棒用轮询模式，CPU占用率直接飙到95% |
| 功耗 | mW | 收发器状态、时钟频率、总线空闲策略 | 某个电池供电的OTG外设，只因为DMA没及时休眠，半小时耗完电 |
4.2 吞吐量：能传多快？
吞吐量最直接的理解就是单位时间能传多少数据。USB 3.0理论上5 Gbps，但实际总线利用率往往只有60%-70%。为什么？
我举个例子：某次做高速数据采集卡，理论带宽540 MB/s，结果实测不到300 MB/s。查出来三个问题：
- 端点缓冲区只配了256字节 —— 每个微帧都要多个事务才能发完一个数据包
- DMA没有用双缓冲 —— 拷贝期间总线空闲
- USB控制器中断频率设成每个包都中断 —— 中断开销占了CPU太多时间
改成4KB缓冲区 + 双缓冲DMA + 成批中断后，直接上到480 MB/s。
吞吐量调优口诀：
- 缓冲区越大越好（但要平衡内存）
- DMA双缓冲/环形缓冲是标配
- 中断合并/NAK处理要合理
- USB帧调度（微帧/帧间隔）别乱改，除非你很懂host控制器
4.3 延迟：响应够快吗？
延迟是另一个维度。你想想，视频通话、游戏外设、工业控制——这些场景对延迟极度敏感。USB协议里默认就有微帧周期（125μs for USB 3.0），但你实际碰到的不止这个。
我曾经调试一个游戏手柄的OTG适配器，报告延迟经常跳到5ms以上。排查后发现问题出在：主机端用批量传输，而批量传输的调度优先级低。后来改成中断传输，延迟降到1ms以内。但注意：中断传输的带宽占比是有限制的，不能滥用。
| 传输类型 | 延迟典型值 | 适用场景 | 我踩过的坑 |
|---|---|---|---|
| 控制传输 | 高（几十ms） | 枚举、配置 | 不要用于实时数据 |
| 批量传输 | 中（1-10ms） | 大块数据、存储 | 延迟随总线负载波动很大 |
| 中断传输 | 低（0.125-1ms） | 人机交互、传感器 | 注意每微帧最多只能发3个中断事务 |
| 等时传输 | 最低（固定微帧周期） | 音视频流 | 没有重传，丢包直接牺牲质量 |
4.4 CPU占用率：别让CPU累趴
CPU占用率往往被新手忽略。你想想看，嵌入式系统CPU通常只有几百MHz，如果USB协议栈占用了30%以上的CPU，其他任务就麻烦了。
我个人习惯，先看一眼中断频率。一个典型的USB 3.0设备，如果每个数据包都产生中断，中断频率可能高达几十万次每秒，CPU光切上下文就切死了。
优化手段：
- 中断合并：只有达到一定数据量或超时再触发中断
- NAK处理：如果host发来事务但设备没准备好，别一直发NAK轮询，可以用延迟NAK
- DMA offload：CPU只负责配置，数据搬运交给DMA
- 批量提交：一个URB（USB Request Block）里可以塞多个事务
4.5 功耗：电池撑得住吗？
功耗在嵌入式设备里是硬约束。USB OTG设备既可以做host也可以做device，功耗管理就更复杂了。
我印象很深的一个项目：一款便携式医疗设备通过OTG连接超声探头。因为一直让USB控制器处于全速工作状态，电池续航从8小时掉到2小时。
回头看，功耗主要来自：
- USB收发器（PHY）—— 工作时功耗至少几十mW
- 时钟PLL —— 高频时钟会显著增加动态功耗
- DMA和总线 —— 频繁搬运数据导致总线反转
- 外部电源管理 —— 如果没及时挂起设备，或者挂起后没降速
USB协议本身支持：挂起 (suspend)、恢复 (resume)、选择性挂起。但很多嵌入式系统根本没实现这些状态机。
降功耗三板斧：
- 闲时挂起USB总线，进出挂起状态要快速
- 降低不用的时钟频率（比如挂起后切到低速时钟）
- 减少不必要的事务：比如周期性查询的HID设备可以延长轮询间隔
4.6 四维权衡：没有免费的午餐
好了，四个维度都拆完了。现在说说它们之间怎么打架。
最容易理解的例子：为了提高吞吐量，你加大缓冲区，数据累积发送——但延迟就上去了，因为要等缓冲区填满才发。为了降低延迟，你用中断传输且不合并中断——CPU占用率飙升。为了降功耗，你降低时钟频率——吞吐量下降。
你看，没有一个维度能单独优化到极致而不影响其他维度。
那怎么办？我的经验是：先定约束，再优化。
- 如果产品对实时性有硬要求（比如工业控制），延迟是刚需，其他维度在这个基础上尽量优化
- 如果产品是移动设备，功耗是第一约束，吞吐量够用就好
- 如果产品是数据采集卡，吞吐量目标确定了，再平衡CPU和功耗
下面这张图是我自己总结的，每次做项目前都会看一遍。
这张图左半边是吞吐量和CPU占用率——这两个往往是伴生关系：你用中断模式、小块搬运，CPU就累；你批量处理、DMA传递，CPU就轻松，但延迟会变大。右半边是延迟和功耗——你要低延迟就得一直在线，功耗就降不下来；你要低功耗就得经常挂起，延迟就会跳。
总结一句话：没有完美的配置，只有合适的平衡。做每个设计决策前，先问自己：这个项目最不能牺牲的是什么？然后围绕这个核心约束，去优化其他维度。
好，这一章就聊到这儿。下一部分我们会动手搭建调试环境，用实际工具来测量这些指标。你先把这个框架放脑子里，后面每一章都会往里面塞具体技巧。