45 lines
3.2 KiB
Markdown
45 lines
3.2 KiB
Markdown
---
|
||
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 级配置 |
|