Hisport性能上限咨询

Hardware SIG
1

问题背景：

设备是插在Riser卡上的新型号RAID卡，协议为MCTP over SMBus，每20秒会去刷新一次信息，请求5个接口的数据，返回数据长度为255字节。
image
拓扑如下：

image
image274×210 3.32 KB

现象和分析

观察到长时间运行或者反复重启的情况偶现MCU通信告警，分析可能是Hisport阻塞导致的
image

image
image1870×790 143 KB

补充

该问题和RAID卡的I2c概率性访问超时 - 交流互助区 - openUBMC 论坛是同一类问题，已经带上PR raid卡获取数据的方式由并行改为串行防止插件请求队列阻塞-storage-AtomGit | GitCode，但是仍然有概率出现该问题 @yelmh_kno07

咨询内容

想咨询一下基础板Hisport支持的i2c通信频率和数据量上限大概是多少，能否支持Riser卡上每20秒进行5次255字节的SMBus通信

2

答案内容由AI生成，仅供参考：

Hisport I²C通信性能上限咨询分析报告

根据您提供的详细信息和日志分析，现就Hisport支持的I²C通信性能上限及对指定通信负载的支持能力进行评估。

问题背景

  • 设备信息：

    • Riser卡型号：BC83PRUO
    • 位置：chassis，槽位1
    • 厂商：Huawei
    • 描述：Riser(X161+X82)
    • UID：00000001040302044498

  • 通信需求：

    • 协议：MCTP over SMBus
    • 频率：每20秒发起一次
    • 请求次数：每次5个接口
    • 数据量：每次返回总长度为4KB

  • 现象：

    • 长时间运行或反复重启时偶现MCU通信告警（事件码：0x0F00001D）
    • 日志中出现严重超时告警（used time[119s], used time[121s]），表明Hisport链路存在阻塞风险

Hisport I²C通信性能上限分析

1. 通信链路路径与关键组件

graph LR
    A[RAID卡] -->|MCTP over SMBus| B[Hisport接口]
    B --> C[Riser卡MCU]
    C --> D[V1/V2芯片]
    D --> E[BMC]

从技术文档可知：

  • RiserCard_1 通过 I2c_1 总线与其下属芯片通信
  • 在日志中观察到针对 Chip_I2c_01@1010301 的 PluginRequestEx 超时，该请求经由 hwproxy 代理转发至底层硬件
  • SMBus Communication Performance 受限于 CPLDVersion、通信协议效率及总线带宽分配

2. 已知性能参数

I²C/SMBus 总线特性

  • 标准速率：常规I²C总线速率为 400 kbps（即50 KB/s）
  • 文档中 I2c_2 的Speed被明确配置为 400K，可推断系统I²C总线普遍采用此标准速率
  • 实际吞吐量受以下因素影响：
    • 协议开销（地址、ACK/NACK、CRC等）
    • 命令响应间隔
    • 总线仲裁与重试机制

数据传输能力估算

  • 理论最大吞吐量：约 50 KB/s
  • 单次4KB数据请求 理论传输时间：
    $$
    \frac{4096 \text{ bytes}}{50 \times 1024 \text{ bytes/sec}} \approx 82 \text{ms}
    $$
  • 5次请求连续传输总耗时约 410ms（不包括协议封装、处理延迟、排队等待等）

3. 实际瓶颈因素

（1）Hisport链路处理延迟

  • 日志显示 PluginRequestEx 调用出现高达 119-121秒 的响应延迟
  • 此类超时通常由以下原因导致：
    • 总线竞争：多个组件共享同一I²C总线资源
    • MCU处理能力不足：Riser卡MCU需处理PCIe扩展、信号切换、状态监控等多项任务
    • 固件版本问题：CPLDVersion 过时可能导致 I2C/Smbus 通信异常，CPLDVersion 被怀疑为导致芯片通信失败的原因之一
    • 写操作延时配置不当：某些Riser卡MCU升级需配置 DrvWriteDelay，若未适配可能导致帧传输超时

（2）通信协议叠加开销

  • MCTP over SMBus 属于多层协议封装，每层引入额外头部和校验
  • 频繁的MCTP请求会显著增加总线负载
  • 根据 openUBMC 项目文档，SMBus通信带宽受限，需合理调度以避免拥塞

（3）固件与软件行为

  • MCUVersion 的版本可能影响数据访问延迟行为（如 DrvWriteDelay 动态配置）
  • Retimer 设备位于I2C链路上，若其固件异常，也可能影响链路稳定性
  • DftVersion_RiserCardMcuVersion 用于测试MCU版本，若版本不符可能导致通信异常

能力评估与建议

:white_check_mark: 吞吐量需求评估

项目 数值 是否满足
每次数据量 4KB × 5 = 20KB :cross_mark: 超过单周期可用带宽
请求周期 20秒 :white_check_mark:
平均带宽需求 1 KB/s :white_check_mark:
瞬时带宽需求 ~25 KB/s（短时突发） :warning: 接近极限，易引发堵塞

结论：单从带宽看，平均每秒1KB在理论上是可行的，但瞬时20KB的批量读取极易造成I²C总线阻塞，尤其是在已有其他管理任务竞争资源的情况下。

:warning: 潜在风险分析

风险项 依据
总线阻塞 日志中已出现 >100s 的 PluginRequestEx 超时，表明Hisport I²C链路存在严重阻塞
MCU通信告警 明确记录“MCU communication error occurs on PCIe riser card1”，与MCU版本、延时配置相关
协议兼容性隐患 使用MCTP over SMBus在高频率、大报文场景下未经充分验证

优化建议

1. 降低通信频率或拆分请求

  • 将 每20秒一次的5个接口集中查询 改为 轮询机制，错开请求时间
  • 将大块4KB数据读取拆分为多次小块读取（如每次512B），避免单次占用总线过久

2. 检查并升级关键固件版本

  • 确认 CPLDVersion 是否为最新版，老旧版本可能导致I²C/SMBus通信不稳定
  • 获取并验证 MCUVersion 是否支持高频通信场景，必要时升级Riser卡MCU固件

3. 配置驱动层延时参数

  • 参考 Chip 类配置中的 DrvWriteDelay 参数，根据MCU版本动态设置写入延迟：
    "DrvWriteDelay": "string.sub($1, 1, 4) |> expr($1 >= '1.12' ? 0 : 1)"
    确保不会因过快发送导致MCU接收错误帧

4. 启用通信监控与故障恢复

  • 启用 Data Update Frequency Optimization 方法，针对静态数据减少更新频率
  • 配置 ReadRetryTimes 和 WriteRetryTimes 提高容错能力
  • 利用 OpenUBMC 提供的Redfish/Web界面实时监控I²C通信状态

5. 启用备用通信路径（如可能）

  • 若RAID卡支持 NC-SI 或 MCTP over PCIe 等更高效协议，建议优先使用，避免经由Hisport I²C链路

总结

目前的Hisport I²C通信架构难以稳定支持“每20秒进行5次4KB的SMBus通信”这一负载。主要原因如下：

  1. 瞬时数据量过大，在400kbps的I²C总线上会导致长时间占用；
  2. 已有实际日志证明存在严重通信超时（>100s），说明链路已处于高负载甚至故障边缘；
  3. MCU与CPLD固件版本可能未适配高频大报文访问模式。

建议：优先优化通信模式（降低频率、拆分请求），并升级Riser卡相关固件（MCU、CPLD），同时考虑切换至更高带宽的通信协议（如MCTP over PCIe），以保障系统长期运行稳定性。

相关链接：

  1. BMC出现raid卡通信异常后恢复，如何通过BMC 查看hisportI2c 链路数据状态
  2. 咨询I2c总结通信速率配置问题
  3. 【SNMP】snmp新增用户名之后，通过web删除新增的用户，snmp无法再次新增
  4. PCIe插卡的I2C读写怎么调试
  5. openUBMC
3

器件的拓扑是什么样的？Hisport的话单次写上限是1k字节

4

拓扑如下：

image
image274×210 3.32 KB

另外更正一下，读取长度为255字节

5

偶现raid卡 9560-8i通信异常触发告警，一段时间后又消除告警 - 交流互助区 - openUBMC 论坛

好像和我是同一个问题= =

1 个赞
6

通信频率是看CPLD那边给我们转发的i2c速率是多少。Hisport的话单次写数据量上限是1k字节