16 lines
3.1 KiB
Markdown
16 lines
3.1 KiB
Markdown
### 2.1 原始数据链路与采集协议 - 工程基线总结报告
|
||
|
||
| 编号 | 核心议题 | 确立的工程基线 (Baseline Established) | 关键系统配置与修正 (Action Items & Constraints) | 依据/影响 |
|
||
| :--- | :--- | :--- | :--- | :--- |
|
||
| **2.1.1/2.1.2** | **链路与协议** | **协议：** UDP/IPv4。<br>**MTU：** JUMBO Frame **9000 字节**。 | **P0 级约束：** 物理链路仍为 1GbE。此基线是软件上**压榨 1GbE 极限吞吐**的 P1 级优化。 | 最大化有效净载荷，并将 CPU 中断频率降低约 6 倍，保障实时性。 |
|
||
| **2.1.3 (I)** | **NIC 队列深度** | **RX Ring Buffer：** 强制配置为硬件最大值 **8192** [ethtool output]。<br>**中断聚合：** 采取激进聚合策略（例如 `rx-usecs 100`），进一步减少 I/O 线程的 CPU 负载。 | **`ethtool` 配置：** `ethtool -G ens4f1 rx 8192`<br>`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) 验证。<br>**时序策略：** 乱序/丢失数据包采用 **立即丢弃并上报** 策略。 | 模块的 `StatsCollector` 实时监控错误率，并与配置阈值 (例如校验和错误率 $1\%$) 进行比对，超限触发 `MetricsUpdateEvent` 告警。 | CRC32 提供工业级鲁棒性。立即丢弃策略保障了 **P99 \< 1ms** 的低延迟 KPI。 |
|
||
| **2.1.5** | **DMA 与零拷贝** | **基线方案 (A)：** 优化标准 I/O，使用 **`recvmmsg()` 批量接收**。<br>**零拷贝实现：** 从 `recvmmsg()` 接收数据直接写入**页锁定内存池** (`MemoryPool`)，并通过指针传递至下游。 | **备选方案 (B)：** **AF\_XDP** (内核零拷贝) 仅在**I/O线程 CPU 占用率** KPI 不达标时，才启动在 Kylin 4.19 平台上的兼容性验证。 | 批量接收和页锁定内存的组合，旨在以最高兼容性和最低的系统调用开销，实现数据从网卡到 GPU 内存的快速通道。 |
|
||
|
||
-----
|
||
|
||
**下一步行动**：
|
||
|
||
我们已完成 **2.1 原始数据链路与采集协议** 的所有基线确立。接下来，我们将进入下一章节 **2.2 异构 DMA 与内存传输机制** 的讨论，重点将集中于 Host CPU 和 Device GPU 之间的数据移动策略。 |