69 lines
4.3 KiB
Markdown
69 lines
4.3 KiB
Markdown
|
---
|
|||
|
|
tags: []
|
|||
|
|
date created: 星期三, 十一月 19日 2025, 9:58:46 晚上
|
|||
|
|
date modified: 星期三, 十一月 19日 2025, 9:59:01 晚上
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
### 一、 核心概念：MTU 与网络开销
|
|||
|
|
|
|||
|
|
| 概念 | 定义 (专业) | 默认值 (行业标准) |
|
|||
|
|
| :--- | :--- | :--- |
|
|||
|
|
| **MTU** (Maximum Transmission Unit, 最大传输单元) | 网络通信中，单个数据包（或帧）在不被分片（Fragmentation）的情况下，**链路层可承载的最大数据净载荷**（Payload）尺寸。 | **1500 字节** |
|
|||
|
|
| **开销** (Overhead) | 每个数据包除了净载荷外，还必须包含的固定长度的网络协议头（如以太网头、IP 头、UDP 头等）。 | **约 42 - 54 字节** |
|
|||
|
|
|
|||
|
|
### 二、 默认 MTU (1500) 在雷达高吞吐场景的局限性
|
|||
|
|
|
|||
|
|
在雷达数据采集（高速、大容量的 UDP 数据流）场景中，使用默认的 MTU 1500 字节会产生两个致命的性能问题：
|
|||
|
|
|
|||
|
|
#### 1. 吞吐效率低下 (Efficiency)
|
|||
|
|
|
|||
|
|
- 在 MTU 1500 的情况下，每个数据包中，实际用于传输雷达数据的净载荷仅占 $1500 / (1500 + \text{Headers})$。
|
|||
|
|
- 如果雷达数据流的速率是 $1000 \text{Mbps}$ (1GbE 的理论上限)，其中有高达 $3\%-5\%$ 的带宽会被固定协议头开销占据，实际用于净数据的带宽进一步降低。
|
|||
|
|
|
|||
|
|
#### 2. CPU 中断风暴 (The Interrupt Storm)
|
|||
|
|
|
|||
|
|
这是实时系统中最关键的问题。
|
|||
|
|
|
|||
|
|
- 为了传输大量数据，操作系统和网卡必须将数据流切割成无数个 1500 字节的小块。
|
|||
|
|
- 每接收一个数据包，网卡通常会触发一次**硬件中断（IRQ）**来通知 CPU 内核数据已到达。
|
|||
|
|
- 在 1GbE 链路满负荷运行时，CPU 需要在**每秒处理数十万次**的网卡中断。
|
|||
|
|
- **后果：** 频繁的中断处理会导致 CPU 大量时间花费在**上下文切换 (Context Switching)** 和中断服务例程上，而不是执行您的核心信号处理算法。这将显著推高系统 CPU 占用率（`sys cpu`），破坏实时性。
|
|||
|
|
|
|||
|
|
### 三、 JUMBO Frame (MTU 9000) 的引入与价值
|
|||
|
|
|
|||
|
|
“JUMBO Frame”是一种非标准的、通过配置将 MTU **放大到 9000 字节左右**的技术。它不是一种新协议，而是对现有以太网协议参数的扩展。
|
|||
|
|
|
|||
|
|
#### 1. 核心价值：极大减少 CPU 中断频率
|
|||
|
|
|
|||
|
|
将 MTU 从 1500 提升到 9000 字节，意味着：
|
|||
|
|
|
|||
|
|
- **数据量不变，中断次数减少 6 倍。** 传输相同的数据量，现在只需要发送六分之一的数据包数量。
|
|||
|
|
- **结果：** CPU 从每秒处理数十万次中断，降低到每秒处理数万次中断。这极大地减轻了内核的压力，将 CPU 资源释放回用户态，保障了您的雷达实时处理线程能够获得更稳定的调度时间。
|
|||
|
|
|
|||
|
|
#### 2. 吞吐效率提升 (Header Compression)
|
|||
|
|
|
|||
|
|
- 在 MTU 9000 下，协议头开销在整个帧中的占比被稀释到**小于 $0.5\%$**，几乎所有的带宽都用于传输雷达净载荷。
|
|||
|
|
- **结论：** 在您当前**受限于 1GbE 硬件** 的情况下，MTU 9000 是确保 1GbE 链路能跑满**最接近 $1 \text{Gb/s}$ 的有效吞吐量**的**P1 级软件优化**。
|
|||
|
|
|
|||
|
|
### 四、 技术实施要求与基线确立
|
|||
|
|
|
|||
|
|
MTU 9000 不是一个自动生效的配置，它是一个**端到端（End-to-End）**的协商机制。
|
|||
|
|
|
|||
|
|
| 环节 | 要求 (基线) |
|
|||
|
|
| :--- | :--- |
|
|||
|
|
| **Host NIC** (您的麒麟服务器) | **必须**通过 `ip link set dev ens4f1 mtu 9000` 命令将 NIC 接口 (例如 `ens4f1`) 的 MTU 设为 9000。 |
|
|||
|
|
| **DPU/ADC** (雷达前端) | **必须**将其发送端的 MTU 设为 **9000 字节**或相同的数值。 |
|
|||
|
|
| **网络设备** (交换机/路由器) | 如果数据路径中有交换机等中间设备，**所有中间设备**的端口也必须开启并配置 MTU 9000，否则将导致数据包被丢弃或分片（后者会重新引入 CPU 开销）。 |
|
|||
|
|
|
|||
|
|
**最终基线结论：**
|
|||
|
|
|
|||
|
|
鉴于硬件瓶颈，采用 **UDP/IP + JUMBO Frame (MTU 9000 字节)** 是在当前 Feiteng/Kylin 平台上实现雷达数据采集链路性能最大化的**核心基线**。
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
**下一步讨论：**
|
|||
|
|
|
|||
|
|
如果您确认了 MTU 9000 的基线，我建议我们进入下一阶段，讨论如何从内核层面配合这一高吞吐策略，即 `2.1.3 NIC 硬件资源与队列管理` 和 `2.1.5 DMA 与内核旁路策略`。
|
|||
|
|
|
|||
|
|
**提问：** 在确认 JUMBO Frame 基线后，您对 **NIC 环形缓冲区 (Ring Buffer)** 的深度配置是否有初步的性能或资源偏好？（这是一个直接影响丢包率的关键参数）
|