I
Editorial
车队或多机实验床一键拉起后，CPU 被 DDS 发现占满、风扇狂转，业务节点还没开始干活——很常见被误判成「机器性能不够」或「某个节点写炸了」。更常见的是 Participant 过多、域未隔离、组播风暴或发现周期过密。本帖整理「先确认是发现而非业务话题 → 再收 Participant/域 → 最后调 QoS/传输」的清单。
一、先确认是不是发现风暴
1. 启动后立刻 CPU 高、话题尚无稳定发布：优先查 discovery；业务算力尖峰通常随订阅与传感器帧率出现。
2. 用系统监控看是否大量 UDP 组播/单播打满某个核；对照 DDS 实现的 discovery 线程。
3. 单机正常、多机同网段一起炸：高度怀疑共享域 + 组播范围过大。
二、Participant 与进程模型
1. 每个进程一个 Participant 时，节点拆太碎会线性放大发现表；能合并的生命周期节点尽量同进程。
2. 启动顺序：先基础设施（记录、tf、公共参数）再批量感知节点，避免 N 台同时全量宣告。
3. 退出要干净：崩溃残留的租约未过期时，其他机会持续重试匹配，表现为「停了一台反而更吵」。
三、域与网络隔离
1. 不同车队/实验床使用不同 Domain ID；同网段多项目混域是发现风暴重灾区。
2. 组播范围：开发机与车载网是否二层互通要心中有数；必要时用对等发现或限制接口。
3. 防火墙/交换机未知组播处理：有的环境会把组播变成泛洪，表象与 DDS 配置无关。
四、QoS 与传输
1. 发现周期与租约：过密的 announcement 在大车队上先伤 CPU；按规模拉长并做压测。
2. 大消息与发现分开看：图像/点云走的共享内存或专用通道，不要和发现调参混为一谈。
3. 多网卡：指定用于 DDS 的接口，避免发现包从错误网卡出去再被转发一圈。
五、验收建议
1. 记录冷启动 N 台时的 CPU、UDP pps、Participant 数量曲线。
2. 变更域、启动编排、DDS 配置同版本入库。
3. 禁止为「先跑起来」把所有节点丢进 Domain 0 还不做隔离。
六、常见误区
- 一飙高就加 CPU，不查域与进程数。
- 开发笔记本与车队同域同网段长期共存。
- 用关防火墙当常规方案。
欢迎补充你们在 Fast DDS / CycloneDDS、以及实车多网段下的发现隔离经验。
一、先确认是不是发现风暴
1. 启动后立刻 CPU 高、话题尚无稳定发布：优先查 discovery；业务算力尖峰通常随订阅与传感器帧率出现。
2. 用系统监控看是否大量 UDP 组播/单播打满某个核；对照 DDS 实现的 discovery 线程。
3. 单机正常、多机同网段一起炸：高度怀疑共享域 + 组播范围过大。
二、Participant 与进程模型
1. 每个进程一个 Participant 时，节点拆太碎会线性放大发现表；能合并的生命周期节点尽量同进程。
2. 启动顺序：先基础设施（记录、tf、公共参数）再批量感知节点，避免 N 台同时全量宣告。
3. 退出要干净：崩溃残留的租约未过期时，其他机会持续重试匹配，表现为「停了一台反而更吵」。
三、域与网络隔离
1. 不同车队/实验床使用不同 Domain ID；同网段多项目混域是发现风暴重灾区。
2. 组播范围：开发机与车载网是否二层互通要心中有数；必要时用对等发现或限制接口。
3. 防火墙/交换机未知组播处理：有的环境会把组播变成泛洪，表象与 DDS 配置无关。
四、QoS 与传输
1. 发现周期与租约：过密的 announcement 在大车队上先伤 CPU；按规模拉长并做压测。
2. 大消息与发现分开看：图像/点云走的共享内存或专用通道，不要和发现调参混为一谈。
3. 多网卡：指定用于 DDS 的接口，避免发现包从错误网卡出去再被转发一圈。
五、验收建议
1. 记录冷启动 N 台时的 CPU、UDP pps、Participant 数量曲线。
2. 变更域、启动编排、DDS 配置同版本入库。
3. 禁止为「先跑起来」把所有节点丢进 Domain 0 还不做隔离。
六、常见误区
- 一飙高就加 CPU，不查域与进程数。
- 开发笔记本与车队同域同网段长期共存。
- 用关防火墙当常规方案。
欢迎补充你们在 Fast DDS / CycloneDDS、以及实车多网段下的发现隔离经验。