131 lines
5.9 KiB
Markdown
131 lines
5.9 KiB
Markdown
---
|
||
tags: []
|
||
date created: 星期五, 十一月 21日 2025, 3:15:00 下午
|
||
date modified: 星期一, 十一月 24日 2025, 4:31:51 下午
|
||
---
|
||
|
||
# 2.3.5 系统负载保护与热节流控制 (System Load Protection & Thermal Throttling)
|
||
|
||
## 一、 约束输入与对齐 (Constraints & Alignment)
|
||
|
||
基于变更后的架构目标，我们需对齐以下硬性约束：
|
||
|
||
1. **触发源单一性**：仅响应**物理传感器告警**（温度、功耗）。显控 UI 操作不再作为触发源。
|
||
2. **响应滞后性 (Hysteresis)**：热惯性是缓慢的。控制逻辑必须包含**迟滞（Hysteresis）**机制，防止在阈值附近频繁切换导致系统震荡（Flapping）。
|
||
3. **执行确定性**：节流动作必须是**确定性的降速**（如每帧固定休眠），而非不确定的丢包。丢包应由上游的背压机制（Backpressure）自然处理，而不是由计算模块主动丢弃。
|
||
|
||
---
|
||
|
||
## 二、 权衡分析与选项呈现 (Trade-off Matrix)
|
||
|
||
### 议题 1：降级执行策略 (Throttling Execution)
|
||
|
||
|**选项**|**A. 丢弃任务 (Task Dropping)**|**B. 动态降频 (DVFS / Clock Gating)**|**C. 软件占空比控制 (Software Duty Cycle) (推荐)**|
|
||
|---|---|---|---|
|
||
|**机制**|直接丢弃输入的 `DataContext`，不进行计算。|调用驱动 API (`ixsmi`) 强制降低 GPU 时钟频率。|在主处理循环中插入 `sleep()`，人为制造流水线气泡。|
|
||
|**热效应**|**极好**。GPU 完全空闲。|**好**。降低电压和频率。|**可控**。通过调整休眠时长精确控制负载率。|
|
||
|**副作用**|**数据断层**。破坏目标跟踪的连续性。|**依赖驱动**。智铠 SDK 可能未开放用户态调频接口，且响应慢。|**延迟增加**。但数据流保持连续，仅吞吐下降。|
|
||
|**适用性**|仅限 Level 3 (紧急停机)。|固件层保护（最后一道防线）。|**应用层首选**。通用、简单、不丢数据。|
|
||
|
||
### 议题 2：控制回路设计 (Control Loop)
|
||
|
||
|**选项**|**A. 简单阈值 (Simple Threshold)**|**B. 迟滞比较器 (Hysteresis Comparator) (推荐)**|
|
||
|---|---|---|
|
||
|**机制**|>90°C 降速，<90°C 恢复。|>90°C 降速 (Trigger)，<80°C 恢复 (Release)。|
|
||
|**稳定性**|**差**。会在 90°C 附近反复震荡，导致风扇啸叫和电流波动。|**高**。确保系统冷却到安全区间后才恢复全速。|
|
||
|
||
---
|
||
|
||
## 三、 基线确立与实施规范
|
||
|
||
为了在极端工况下保护硬件同时维持最低限度的业务连续性，我们确立 **C. 软件占空比控制** + **B. 迟滞比较器** 为基线。
|
||
|
||
### 1. 交互协议基线 (Protocol)
|
||
|
||
定义一套闭环的保护协议：
|
||
|
||
- **告警事件 (Alert)** - 由 `MonitoringModule` 发布：
|
||
- `SystemOverloadEvent { Type: THERMAL | POWER; Level: WARNING | CRITICAL; Value: float; }`
|
||
- _WARNING_: 接近阈值（如 85°C）。
|
||
- _CRITICAL_: 超过阈值（如 95°C）。
|
||
- **指令事件 (Command)** - 由 `ResourceCoordinator` 发布：
|
||
- `SetComputeThrottleEvent { ThrottleLevel level; TraceID trace_id; }`
|
||
|
||
### 2. 节流分级定义 (Throttle Levels)
|
||
|
||
|**等级**|**定义 (Level)**|**行为规范 (Behavior)**|**目标负载 (GPU Usage)**|**触发场景**|
|
||
|---|---|---|---|---|
|
||
|**L0**|**NO_THROTTLE**|全速运行，无额外休眠。|100% (Max)|温度 < 80°C|
|
||
|**L1**|**LIGHT**|每帧处理后休眠 **5ms**。|~80%|80°C < 温度 < 90°C|
|
||
|**L2**|**HEAVY**|每帧处理后休眠 **20ms**。|~50%|温度 > 90°C|
|
||
|**L3**|**SUSPEND**|**暂停计算**。停止从队列取数据（触发背压）。|0% (Idle)|温度 > 95°C (濒临宕机)|
|
||
|
||
### 3. 迟滞控制逻辑 (Hysteresis Logic)
|
||
|
||
- **位置**：`TaskScheduler` 中的 `ResourceCoordinator` 组件。
|
||
- **逻辑**：
|
||
|
||
```cpp
|
||
// 伪代码：迟滞状态机
|
||
void onTemperatureUpdate(float temp) {
|
||
static State state = NORMAL;
|
||
|
||
switch (state) {
|
||
case NORMAL:
|
||
if (temp > 90.0) { state = THRORRLE_L2; publish(LEVEL_2); }
|
||
else if (temp > 85.0) { state = THRORRLE_L1; publish(LEVEL_1); }
|
||
break;
|
||
case THRORRLE_L1:
|
||
if (temp > 90.0) { state = THRORRLE_L2; publish(LEVEL_2); }
|
||
else if (temp < 75.0) { state = NORMAL; publish(LEVEL_0); } // 迟滞回落
|
||
break;
|
||
case THRORRLE_L2:
|
||
if (temp < 80.0) { state = THRORRLE_L1; publish(LEVEL_1); } // 迟滞回落
|
||
break;
|
||
}
|
||
}
|
||
```
|
||
|
||
### 4. 模块侧实现规范
|
||
|
||
- **组件**：在 `SignalProcessor` 中新增 `ThrottleController` 类。
|
||
- **侵入点**：`ExecutionEngine` 的主循环末尾。
|
||
- **实现**：
|
||
|
||
```cpp
|
||
void ExecutionEngine::run() {
|
||
while (running_) {
|
||
// 1. 获取数据 & 2. 提交计算 (…原逻辑…)
|
||
|
||
// 3. 节流控制点 (新增)
|
||
throttle_controller_.applyDelay();
|
||
}
|
||
}
|
||
|
||
void ThrottleController::applyDelay() {
|
||
// 读取原子变量，避免锁竞争
|
||
auto level = current_level_.load(std::memory_order_relaxed);
|
||
if (level == L1) std::this_thread::sleep_for(5ms);
|
||
else if (level == L2) std::this_thread::sleep_for(20ms);
|
||
else if (level == L3) std::this_thread::sleep_for(100ms); // 轮询等待
|
||
}
|
||
```
|
||
|
||
---
|
||
|
||
## 总结与下一步行动
|
||
|
||
我们确立了 **2.3.5 系统负载保护** 的基线：
|
||
|
||
1. **机制**：**软件级休眠 (Duty Cycle)**，牺牲延迟换取降温。
|
||
2. **策略**：**四级节流 + 迟滞控制**，防止系统震荡。
|
||
3. **触发**：仅限 **物理过载**。
|
||
|
||
下一步建议：
|
||
|
||
控制面的“指挥”和“保护”都做好了。现在我们要解决最具挑战性的“动态调整”问题 —— 2.3.6 两阶段配置热更新协议。
|
||
|
||
比如，如何在雷达正在运转时，安全地把 CFAR 检测阈值从 15dB 改为 13dB，或者切换波束扫描策略，而不需要重启整个进程？这需要一套严密的事务协议。
|
||
|
||
**提问**：您是否确认 **“四级节流 + 迟滞控制”** 的保护基线？确认后我们将深入 2.3.6。
|