Inbox/系统基座文件/2.1 工程基线总结报告_原始数据链路与采集协议.md

2.1 原始数据链路与采集协议 - 工程基线总结报告

编号	核心议题	确立的工程基线 (Baseline Established)	关键系统配置与修正 (Action Items & Constraints)	依据/影响
2.1.1/2.1.2	链路与协议	协议： UDP/IPv4。 MTU： JUMBO Frame 9000 字节。	P0 级约束： 物理链路仍为 1GbE。此基线是软件上压榨 1GbE 极限吞吐的 P1 级优化。	最大化有效净载荷，并将 CPU 中断频率降低约 6 倍，保障实时性。
2.1.3 (I)	NIC 队列深度	RX Ring Buffer： 强制配置为硬件最大值 8192 [ethtool output]。 中断聚合： 采取激进聚合策略（例如 rx-usecs 100），进一步减少 I/O 线程的 CPU 负载。	ethtool 配置： ethtool -G ens4f1 rx 8192 ethtool -C ens4f1 rx-usecs 100 rx-frames 256	提供了最长的瞬态延迟容忍度，是实现数据包丢失率 < 0.01% KPI 的重要保障。
2.1.3 (II)	CPU 亲和性	硬绑定： 数据接收模块（I/O 线程和工作线程）必须强制绑定到 NUMA Node 1 (CPU 16-31)。	P0 级修正： 必须使用 numactl --cpunodebind=1 --membind=1 启动应用程序。	消除跨 NUMA 节点访问 GPU 页锁定内存 (MemoryPool) 导致的高延迟和抖动。
2.1.3 (III)	内核内存修正	内核 Socket 缓冲区： 必须提升内核参数 net.core.rmem_max 的硬上限。	P1 级修正： 将 net.core.rmem_max 提升至至少 64MB (例如 sysctl -w net.core.rmem_max=67108864)，以确保能容纳 8192 个 MTU 9000 的巨型帧。	解决当前 2MB 内核限制导致的静默丢包风险。
2.1.4	数据完整性	校验和标准： 采用应用层 CRC32 校验，由雷达前端生成并由 PacketProcessor (ChecksumValidator) 验证。 时序策略： 乱序/丢失数据包采用 立即丢弃并上报 策略。	模块的 StatsCollector 实时监控错误率，并与配置阈值 (例如校验和错误率 1\%) 进行比对，超限触发 MetricsUpdateEvent 告警。	CRC32 提供工业级鲁棒性。立即丢弃策略保障了 P99 < 1ms 的低延迟 KPI。
2.1.5	DMA 与零拷贝	基线方案 (A)： 优化标准 I/O，使用 recvmmsg() 批量接收。 零拷贝实现： 从 recvmmsg() 接收数据直接写入页锁定内存池 (MemoryPool)，并通过指针传递至下游。	备选方案 (B)： AF_XDP (内核零拷贝) 仅在I/O线程 CPU 占用率 KPI 不达标时，才启动在 Kylin 4.19 平台上的兼容性验证。	批量接收和页锁定内存的组合，旨在以最高兼容性和最低的系统调用开销，实现数据从网卡到 GPU 内存的快速通道。

---

下一步行动：

我们已完成 2.1 原始数据链路与采集协议 的所有基线确立。接下来，我们将进入下一章节 2.2 异构 DMA 与内存传输机制 的讨论，重点将集中于 Host CPU 和 Device GPU 之间的数据移动策略。