创建仓库

系统基座文件/2/2.1/2.1.2 数据链路层协议与封装 (Data Link Layer Protocol & Encapsulation).md

@@ -0,0 +1,44 @@
+---
+tags: []
+date created: 星期三, 十一月 19日 2025, 10:14:33 晚上
+date modified: 星期三, 十一月 19日 2025, 10:14:46 晚上
+---
+
+### 2.1.2 数据链路层协议与封装 (Data Link Layer Protocol & Encapsulation)
+
+- **概要**: 本节旨在确立雷达数据采集链路的 L2/L3 层协议与最大传输单元 (MTU) 规格。鉴于系统存在 **P0 级 1GbE 硬件带宽瓶颈**，为最大化有效数据吞吐并保障实时性，协议基线选择标准 **UDP/IP**，并强制采用 **JUMBO Frame (MTU 9000)** 技术，以实现对网络性能的 P1 级优化。
+
+---
+
+#### 1. 协议基线与 MTU 确立
+
+| 基线元素 | 确立值 | 论证 |
+| :--- | :--- | :--- |
+| **传输协议** | UDP/IPv4 | 采用标准 UDP 协议，以满足雷达数据流对**无连接、低延迟**的传输特性要求，牺牲可靠性（由应用层序列号校验弥补）。 |
+| **MTU** | **9000 字节** (JUMBO Frame) | 旨在将**网络开销最小化**，并将 **CPU 中断频率降低 6 倍**，是当前 1GbE 链路下达成高吞吐 KPI 的关键优化手段。 |
+| **数据封装** | 定制雷达数据包头部 | 必须在 9000 字节 MTU 限制内，封装 **TraceID**、**序列号**和 **校验和** 字段。 |
+
+#### 2. 技术论证：JUMBO Frame 的核心价值
+
+MTU 9000 的选择并非只是带宽的简单放大，它在当前 **Kylin/Feiteng** 实时处理平台上提供了两大核心工程优势：
+
+##### 2.1. 实时性保障：消除 CPU 中断风暴
+
+- **问题描述**: 在 1GbE 链路满载且使用标准 MTU 1500 字节时，CPU 内核每秒需处理约 **81,000 个**数据包中断（不考虑中断聚合）。这种高频的中断会导致 CPU 资源大量消耗在**上下文切换**和**中断服务**上，严重破坏实时性。
+- **解决方案**: 将 MTU 提升至 9000 字节后，传输相同的数据量所需的中断次数降为原来的 **约 1/6**。这极大地减轻了内核压力，将 CPU 资源释放回用户态，有助于满足 **CPU 资源占用率 \< 5% (单核)** 的 KPI。
+
+##### 2.2. 吞吐效率：最小化协议开销
+
+- **问题描述**: 在 MTU 1500 下，每个数据包的协议头（约 42 字节）占据了约 3% 的有效带宽。
+- **解决方案**: JUMBO Frame 将协议头开销稀释至 **0.5% 以下**。这在 1GbE 这种物理瓶颈链路 上至关重要，它确保了链路能最大限度地传输**雷达净载荷**，为达到 **数据吞吐量 KPI** 提供软件保障。
+
+#### 3. 实施规范与系统依赖
+
+JUMBO Frame 的实现是一个**端到端**的配置基线，需要严格遵循以下规范：
+
+| 实施环节 | 规范操作 | 状态 |
+| :--- | :--- | :--- |
+| **Host NIC 配置** | 必须通过 `ethtool` 或 `ip link` 命令，将采集接口的 MTU 强制设定为 9000 字节。 | 已确认 |
+| **雷达前端配置** | 雷达阵面 DPU/ADC 的发送端 MTU 必须精确匹配 9000 字节。 | 外部依赖 |
+| **内核缓冲区** | 必须修正内核参数 `net.core.rmem_max`，使其容量足以承载 **8192** 个 MTU 9000 的数据包。当前需将 `rmem_max` 提升至至少 **64MB** 以消除丢包风险 [sysctl output]。 | P1 级修正 |
+| **NIC 环形缓冲区** | RX 队列深度必须配置为硬件最大值 **8192** [ethtool output]，以提供最长的瞬态延迟容忍度。 | P1 级配置 |