4. IEEE 802.1Qat 流整形：CBS算法原理、带宽分配策略、实际配置案例
好，咱们今天聊聊流整形。说实话，AVB协议栈里，CBS（Credit-Based Shaper）是我个人觉得最巧妙的设计之一。它不像传统以太网那样“谁抢到谁发”，而是给每个流分配一个“信用额度”。你想想看，这就像给每个数据流开了一个银行账户，有存款才能消费。
4.1 CBS算法的核心原理
CBS算法的本质，说白了就是“积分制”。每个AVB流（我们叫它SR类流）都有一个积分器。这个积分器会随时间增加，发送数据时则减少。积分不能为负，也不能超过一个上限。
我刚开始接触这个算法时，总觉得它跟令牌桶很像。但实际用起来，区别还挺大的。令牌桶是“有令牌才能发”，CBS是“有信用才能发，但信用可以欠着”。嗯，这里要注意，CBS的信用值可以为负，但负值有下限。
关键参数：
- idleSlope：信用值增加速率（单位：bits/s）
- sendSlope：信用值减少速率（单位：bits/s）
- hiCredit：信用值上限
- loCredit：信用值下限（负值）
算法流程其实很简单：
- 如果队列中有帧等待发送，且信用值 ≥ 0，则允许发送
- 发送时，信用值以 sendSlope 速率减少
- 不发送时，信用值以 idleSlope 速率增加
- 信用值不能超过 hiCredit，也不能低于 loCredit
为什么会这样设计？我给大家举个例子。假设你有一个音视频流，需要保证每125微秒发送一个帧。如果网络突然拥堵，你的信用值会变成负数。等网络空闲了，信用值慢慢恢复，你就能“补发”之前积压的数据。这就是CBS的平滑能力。
4.2 带宽分配策略
带宽分配是CBS最核心的工程问题。我记得在某个车载项目中，客户要求同时支持3路高清视频流和8路音频流。当时我就在想，怎么分才合理？
IEEE 802.1Qat规定，AVB总带宽不能超过链路带宽的75%。剩下的25%留给传统以太网流量（BE，Best Effort）。这个比例不是随便定的，我实测过，超过75%后，CBS的整形效果会明显下降。
| SR类 | 优先级 | 典型应用 | 带宽占比建议 |
|---|---|---|---|
| SR-A | 3 | 视频流、摄像头 | 30%-40% |
| SR-B | 2 | 音频流、传感器 | 10%-20% |
| BE | 0-1 | 诊断、OTA升级 | 25%-40% |
实际配置时，我建议遵循以下原则：
- 先算总账：所有SR类流的总带宽 ≤ 链路带宽 × 75%
- 再分等级：SR-A的idleSlope要大于SR-B，保证视频优先
- 留余量：别把带宽算死，留10%给突发流量
个人经验：我曾经在一个项目中，把SR-A的带宽配到了45%，结果BE流量几乎无法工作。后来发现，75%的限制是针对所有SR类的总和，不是单个类。调整后，系统就稳定了。
4.3 实际配置案例
好，咱们来点干货。下面是一个实际的车载以太网配置案例。假设我们有一个100Mbps的链路，需要支持：
- 1路1080p视频流（约30Mbps）
- 4路音频流（每路约1.5Mbps）
- 剩余带宽给诊断和OTA
首先，计算总SR带宽：30 + 4×1.5 = 36Mbps。链路带宽的75%是75Mbps，所以36Mbps完全OK。
接下来，配置CBS参数。我习惯用下面的公式：
idleSlope = 分配的带宽（bits/s）
sendSlope = 链路速率 - idleSlope
hiCredit = 最大帧长 × (sendSlope / 链路速率)
loCredit = -最大帧长 × (idleSlope / 链路速率)嗯，这里要注意，最大帧长通常取1542字节（含前导码）。
具体配置如下：
// SR-A类（视频流）
idleSlope = 30,000,000 bits/s
sendSlope = 100,000,000 - 30,000,000 = 70,000,000 bits/s
hiCredit = 1542 × 8 × (70,000,000 / 100,000,000) = 8635 bits
loCredit = -1542 × 8 × (30,000,000 / 100,000,000) = -3701 bits
// SR-B类（音频流，4路共享）
idleSlope = 6,000,000 bits/s
sendSlope = 100,000,000 - 6,000,000 = 94,000,000 bits/s
hiCredit = 1542 × 8 × (94,000,000 / 100,000,000) = 11596 bits
loCredit = -1542 × 8 × (6,000,000 / 100,000,000) = -740 bits避坑指南：我曾经犯过一个错误，把hiCredit算得太大。结果视频流在空闲时积攒了大量信用，一旦开始发送，瞬间占满整个链路，导致音频流出现卡顿。后来我把hiCredit限制在2倍最大帧长以内，问题就解决了。
配置完成后，建议用网络分析仪抓包验证。重点关注两点：
- SR类流的发送间隔是否均匀
- BE流是否还能正常工作
如果发现SR类流出现“突发发送”，多半是hiCredit设置过大。如果BE流长时间得不到发送机会，可能是idleSlope分配过多。
4.4 调试与优化技巧
最后，分享几个我在项目中积累的调试技巧：
- 先跑单流：只配置一个SR类流，验证CBS基本功能
- 逐步加压：从50%带宽开始，逐步增加到75%
- 观察信用值：通过寄存器读取实时信用值，看是否频繁触底
- 注意时钟同步：CBS依赖精确的时间，gPTP必须正常工作
说实话，CBS调试最折磨人的地方在于，问题往往不是立刻暴露的。可能跑几个小时才出现一次抖动。我建议做至少24小时的稳定性测试，特别是音视频同步的场景。
好了，关于CBS算法，咱们就聊到这儿。下一章我会讲SRP（流预留协议），到时候咱们看看怎么自动协商这些带宽参数。