295 lines
13 KiB
Markdown
295 lines
13 KiB
Markdown
# 方向7：方法论与评估工具链
|
||
|
||
## 1. 方法论总框架
|
||
|
||
本研究的方法论围绕下面这个核心判断展开：
|
||
|
||
> **在五类部署形态下，大型跨平台实时操作系统在任务关键系统中支撑人工智能目标负载、维持关键保障负载实时边界的系统表现，以及其相对于普通 Linux 与 PREEMPT_RT Linux 的差异。**
|
||
|
||
因此，方法论采用 **“准入 → 对照 → 建模 → 机制实现 → 实测验证 → 跨档位分析”** 的闭环。
|
||
|
||
```
|
||
┌─────────────────────────────────────────────────────────┐
|
||
│ Step 1: 平台与测量准入 │
|
||
│ - 设备、OS、加速器、模型、计时链路、功率计 │
|
||
├─────────────────────────────────────────────────────────┤
|
||
│ Step 2: 公平对照设计 │
|
||
│ - O0 普通 Linux / O1 PREEMPT_RT / O2-O3 SylixOS │
|
||
├─────────────────────────────────────────────────────────┤
|
||
│ Step 3: 负载建模 │
|
||
│ - 人工智能目标负载 / 关键保障负载 / 伴生竞争负载 │
|
||
├─────────────────────────────────────────────────────────┤
|
||
│ Step 4: 机制实现 │
|
||
│ - 调度、隔离、内存、中断、准入、能耗与热管理 │
|
||
├─────────────────────────────────────────────────────────┤
|
||
│ Step 5: 实测验证 │
|
||
│ - 双目标达标、长稳、恢复、消融、统计显著性 │
|
||
├─────────────────────────────────────────────────────────┤
|
||
│ Step 6: 跨档位分析 │
|
||
│ - T5~T1 五类部署形态、11 个代表档位的规律与边界 │
|
||
└─────────────────────────────────────────────────────────┘
|
||
```
|
||
|
||
## 2. 研究对象、对照对象与验证矩阵
|
||
|
||
### 2.1 研究对象
|
||
|
||
主研究对象是：
|
||
|
||
- **大型跨平台实时操作系统这一类平台**
|
||
- 其中 `SylixOS` 是主实验样例
|
||
- `QNX`、`VxWorks`、`INTEGRITY`、`LynxOS-178` 等可作为外部参照样本
|
||
- 其实时调度、资源隔离、中断管理、内存管理和恢复机制
|
||
|
||
### 2.2 对照对象
|
||
|
||
后续所有实验统一采用三层 OS 对照：
|
||
|
||
| 编号 | 对照对象 | 作用 |
|
||
|---|---|---|
|
||
| `O0` | 普通 Linux | 通用系统基线 |
|
||
| `O1` | PREEMPT_RT Linux | 实时增强型通用系统基线 |
|
||
| `O2` | SylixOS 默认配置 | RTOS 原生基线 |
|
||
| `O3` | SylixOS 优化配置 | 主实验样例优化组 |
|
||
|
||
必要时可增加 `O4` 作为 PREEMPT_RT Linux 的等预算调优组，容器或虚拟机仅作为部署方式记录，不单独列为新的“内核类别”。
|
||
|
||
### 2.3 验证矩阵
|
||
|
||
硬件承担关键验证矩阵角色。
|
||
`T5~T1` 五类部署形态和 `11` 个代表档位用于验证系统机制在不同资源条件下的成立范围与边界。
|
||
|
||
这套验证矩阵统一的是建模、测量与对照方法，不预设同一套 RTOS 机制会在所有档位取得相同收益。研究重点是识别不同部署层级下机制有效的条件、收益来源与失效边界。
|
||
|
||
对于 `T2/T1` 这类搭载独立 GPU 或复杂互联的层级，还需要单独区分两类证据：
|
||
|
||
- CPU 侧实时调度、中断隔离、内存预算、关键保障负载保护等系统级证据；
|
||
- 加速器执行、跨卡通信、驱动与运行时行为带来的平台级边界证据。
|
||
|
||
前者属于 RTOS 直接可分析范围，后者作为系统约束和外部边界进入解释框架。
|
||
|
||
## 3. 负载建模：三类负载
|
||
|
||
### 3.1 三类负载定义
|
||
|
||
| 负载类型 | 定义 | 例子 |
|
||
|---|---|---|
|
||
| 人工智能目标负载 | 系统要完成的智能功能本身 | LLM 推理、视觉检测、语义识别、故障诊断 |
|
||
| 关键保障负载 | 维持任务关键系统边界的核心任务 | 1 ms 控制回路、联锁、状态采集、执行闭环 |
|
||
| 伴生竞争负载 | 会争抢资源但不属于主功能的任务 | 日志、更新、存储、网络 I/O、模型加载 |
|
||
|
||
### 3.2 建模目标
|
||
|
||
本研究统一评估三项内容：
|
||
|
||
1. 人工智能目标负载是否按时并有效地完成；
|
||
2. 关键保障负载是否仍满足截止期与抖动边界；
|
||
3. 系统在两类目标并存时是否保持稳定、可解释和可恢复。
|
||
|
||
### 3.3 任务图抽象
|
||
|
||
```
|
||
人工智能目标负载：
|
||
输入处理 → Prefill / 前处理 → 设备计算 → 输出决策 → 结果返回
|
||
|
||
关键保障负载：
|
||
周期释放 → 传感采集 → 控制计算 → 执行输出 → 状态确认
|
||
|
||
伴生竞争负载：
|
||
日志写入 / 网络收发 / 模型加载 / 存储 I/O / 管理服务
|
||
```
|
||
|
||
后续所有调度建模，都围绕这三类负载的竞争关系来分析。
|
||
|
||
## 4. 评价框架：双目标达标 + 系统协同
|
||
|
||
### 4.1 人工智能目标负载指标
|
||
|
||
| 类别 | 指标 |
|
||
|---|---|
|
||
| 时效 | `TTFT`、`TPOT`、端到端响应时间 |
|
||
| 有效性 | 精度、成功率、任务完成率、输出可用性 |
|
||
| 稳定性 | 长时间运行退化、失败率、热漂移影响 |
|
||
|
||
### 4.2 关键保障负载指标
|
||
|
||
| 类别 | 指标 |
|
||
|---|---|
|
||
| 截止期 | `deadline miss ratio` |
|
||
| 尾部行为 | `P99/P99.9 jitter`、观测最大响应时间 |
|
||
| 外部接口 | GPIO / CAN / RS485 / 网络回路端到端响应 |
|
||
|
||
### 4.3 系统协同指标
|
||
|
||
| 类别 | 指标 |
|
||
|---|---|
|
||
| 效率 | 有效吞吐、拒绝率、恢复时间 |
|
||
| 能效 | `E/token`、`tokens/J`、整机功耗 |
|
||
| 稳定性 | 温度、降频时间比例、24 h 长稳表现 |
|
||
| 公平性 | 多任务 / 多模型并发下的资源分配与隔离效果 |
|
||
|
||
因此，论文与实验的通过标准应统一为：
|
||
|
||
> **人工智能目标负载达标 + 关键保障负载达标 + 系统协同稳定。**
|
||
|
||
## 5. 准入机制
|
||
|
||
为了保证后续对照具有可信度，所有平台必须通过分阶段准入：
|
||
|
||
| 门槛 | 核心内容 |
|
||
|---|---|
|
||
| `G0` 设备准入 | 启动、SMP、容量、接口、拓扑正确 |
|
||
| `G1` 测量准入 | 单调时钟、日志、功率计、外部测量链路 |
|
||
| `G2` 加速器准入 | 驱动加载、最小算子、结果回读 |
|
||
| `G3` 模型准入 | 模型转换、加载、推理、释放、重复运行 |
|
||
| `G4` 混合负载准入 | 人工智能目标负载与关键保障负载稳定共存至少 30 分钟 |
|
||
|
||
任何准入失败都要作为研究记录保留。
|
||
|
||
对于 `T2/T1` 扩展层级，如果商业 GPU 驱动生态或平台条件限制了 RTOS 原生实测，需将该层级明确标注为建模分析、条件验证或基线对照证据，不把未完成的 RTOS 原生实测写成正式结果。
|
||
|
||
## 6. 对照原则
|
||
|
||
### 6.1 固定不变项
|
||
|
||
为了保证 OS 对照公平，以下变量必须冻结：
|
||
|
||
- 模型版本、量化格式、tokenizer、输入长度与输出长度；
|
||
- CPU 核数量、优先级、内存预算、加速器数量；
|
||
- 到达流、随机种子、预热时间、采样窗口；
|
||
- PTP 或等效时钟同步方式、时间戳对齐策略与测量链路；
|
||
- 环境温度、散热、驱动与框架版本。
|
||
|
||
### 6.2 允许变化项
|
||
|
||
允许作为自变量扫描的内容包括：
|
||
|
||
- OS 类型与配置；
|
||
- 调度策略与核隔离；
|
||
- IRQ 亲和与中断线程化；
|
||
- 内存限额、KV Cache 预分配与准入控制；
|
||
- 功率与频率策略；
|
||
- 并发度、到达率和背景干扰强度。
|
||
|
||
## 7. 建模与分析方法
|
||
|
||
### 7.1 可调度性与响应时间分析
|
||
|
||
关键保障负载优先使用固定优先级与响应时间分析：
|
||
|
||
```
|
||
R_i^(0) = C_i
|
||
R_i^(k+1) = C_i + Σ_{j∈hp(i)} ⌈R_i^(k) / T_j⌉ × C_j
|
||
```
|
||
|
||
其中：
|
||
|
||
- `C_i` 为关键保障任务的执行时间；
|
||
- `T_j` 为高优先级任务周期；
|
||
- `R_i` 为响应时间。
|
||
|
||
人工智能目标负载根据其服务目标与预算，被建模为：
|
||
|
||
- 可限流的服务任务；
|
||
- 可准入的队列任务；
|
||
- 可隔离的设备任务；
|
||
- 必要时具有阶段性优先级的任务图。
|
||
|
||
当场景包含跨节点协同或外部总线闭环时，还需把时间同步误差、通信抖动和设备完成事件纳入分析参数。对于具备形式化边界的关键保障任务，应进一步结合 WCET 假设、到达模型与调度策略，形成可调度性判定条件。
|
||
|
||
### 7.2 容量与热稳定性分析
|
||
|
||
对人工智能目标负载，需要同时分析：
|
||
|
||
- 模型权重占用；
|
||
- KV Cache 增长；
|
||
- 中间激活与工作区；
|
||
- 运行时与驱动保留区；
|
||
- 温度导致的频率变化。
|
||
|
||
因此，容量与热是实时保障能否成立的前提条件。
|
||
|
||
### 7.3 消融分析
|
||
|
||
系统机制收益通过逐项消融来解释，例如：
|
||
|
||
1. 去掉 CPU 核隔离；
|
||
2. 去掉 IRQ 亲和；
|
||
3. 去掉内存预分配；
|
||
4. 去掉推理准入控制；
|
||
5. 去掉功耗感知策略。
|
||
|
||
每次只移除一个机制，观察双目标达标边界的变化。
|
||
|
||
## 8. 工具链
|
||
|
||
### 8.1 采样与追踪工具
|
||
|
||
| 类别 | 代表工具 |
|
||
|---|---|
|
||
| OS 追踪 | RTOS trace、ftrace、事件日志 |
|
||
| 性能分析 | perf、设备 profiler、定制采样脚本 |
|
||
| 功率与温度 | 外部功率计、PDU、板载传感器、温度记录 |
|
||
| 外设测量 | 示波器、逻辑分析仪、CAN/RS485 分析仪 |
|
||
| 时间同步 | PTP、硬件时间戳、同步误差校验脚本 |
|
||
|
||
下面给出统一测量矩阵，用于把指标、采样工具与观测目的对齐：
|
||
|
||
| 指标类别 | 代表指标 | 主要采样工具 | 观测目的 |
|
||
|---|---|---|---|
|
||
| 人工智能目标负载时效 | `TTFT`、`TPOT`、端到端响应时间 | 应用层时间戳、推理引擎日志、设备 profiler | 判断智能功能是否按服务时限完成 |
|
||
| 人工智能目标负载有效性 | 精度、成功率、任务完成率、输出可用性 | 数据集回放脚本、结果校验脚本、业务判分程序 | 避免只优化时延而牺牲输出质量 |
|
||
| 关键保障负载实时性 | `deadline miss ratio`、观测最大响应时间 | RTOS trace、GPIO 打点、示波器、逻辑分析仪 | 判断关键任务是否仍满足实时边界 |
|
||
| 尾部抖动行为 | `P99/P99.9 jitter`、突发峰值延迟 | 高精度事件日志、外部时序测量、分位统计脚本 | 识别平均值掩盖下的尾部失稳 |
|
||
| CPU 与调度行为 | 核占用、上下文切换、迁核、中断干扰 | perf、ftrace、调度事件日志 | 解释不同 OS 机制下的调度差异 |
|
||
| 内存与容量行为 | 峰值内存、KV Cache 增长、分配失败率 | `/proc`、驱动日志、运行时统计、定制采样脚本 | 判断容量边界与动态分配抖动来源 |
|
||
| 功率与热稳定性 | 整机功耗、芯片温度、降频时间比例 | 外部功率计、PDU、板载传感器、温度记录 | 判断长稳阶段是否因热或供电触发退化 |
|
||
| I/O 与外设链路 | GPIO/CAN/RS485/网络回路时延 | 示波器、总线分析仪、抓包工具 | 验证系统外部闭环而非仅内部线程表现 |
|
||
| 恢复与稳态行为 | 故障恢复时间、重试成功率、24 h 退化曲线 | 守护日志、错误注入脚本、长稳记录程序 | 判断系统是否具备工程可用性 |
|
||
|
||
### 8.2 理论与仿真工具
|
||
|
||
| 类别 | 作用 |
|
||
|---|---|
|
||
| RTA / WCET 分析 | 关键保障负载响应时间边界分析 |
|
||
| 抽象仿真框架 | 参数扫描、到达流与机制对比 |
|
||
| 架构级仿真 | 必要时验证拓扑与内存模型假设 |
|
||
|
||
这里的仿真用于机制理解、参数扫描与拓扑假设验证。
|
||
主线验证平台为 **SylixOS 与其对照系统**。
|
||
|
||
## 9. 实验流程
|
||
|
||
统一实验流程如下：
|
||
|
||
1. 完成 `G0~G4` 准入；
|
||
2. 建立 `O0/O1/O2/O3` 对照组；
|
||
3. 先测空载与仅人工智能目标负载基线；
|
||
4. 再测人工智能目标负载与关键保障负载并存场景；
|
||
5. 加入 CPU / 内存 / I/O / 网络等伴生竞争负载；
|
||
6. 进行长稳、突发、恢复与消融实验；
|
||
7. 进行跨档位和跨部署形态对比。
|
||
|
||
## 10. 可复现性要求
|
||
|
||
每次运行至少保存以下元数据：
|
||
|
||
- 档位、设备编号、OS/BSP/驱动版本；
|
||
- 模型校验值、量化格式、输入模板、随机种子；
|
||
- CPU/IRQ/频率/内存配置；
|
||
- 环境温度、散热方式、测量仪器；
|
||
- 原始延迟、功率、温度与错误日志。
|
||
|
||
只有满足这些条件，后续论文中的“优势”才具备可外部讨论的基础。
|
||
|
||
## 11. 本文档在整个仓库中的作用
|
||
|
||
本文件负责回答三个问题：
|
||
|
||
1. **怎么保证研究对象始终落在 RTOS 平台层；**
|
||
2. **怎么把人工智能目标负载、关键保障负载和伴生竞争负载统一进同一评价框架；**
|
||
3. **怎么在不降低硬件配置与指标颗粒度的前提下，得到可复现、可比较、可解释的证据；**
|
||
4. **怎么用统一方法识别不同部署层级下 RTOS 机制的有效区间与失效边界。**
|
||
|
||
这也是后续 `02-基础设备与算力基础.md`、`03-实验设计.md` 和 `04-论文写作规划.md` 必须共同服从的方法论中轴。
|