工程要点
- 在两台试点设备上，仅使用 PREEMPT_RT 仍未达到 1 ms 最大抖动标准。
- PREEMPT_RT 配合 SCHED_FIFO 优先级 80，在有负载和无负载的四次稳态测试中均通过。
- 该结果只适用于明确限定的 10 ms 试点配置，不代表通用实时或安全认证。
抖动是分布，不是形容词
如果不说明周期、负载、持续时间和最大值，就把 Linux 称为确定性系统，只是营销说法。真正的问题是观测到的最坏情况能否保持在设备时序预算内。[3][4][5]
PREEMPT_RT 让更多内核路径可被抢占；SCHED_FIFO 改变就绪任务的调度优先级。两者解决的是同一时序问题中的不同部分。[2][3]
测试前先写清验收条件
10 ms 测试只有在最大抖动不超过 1 ms、漏周期和超限周期均为零、快照年龄不超过 20 ms、发布不超过 1 ms 时才算通过。[1]
通过测试的配置与数据
PREEMPT_RT 配合 SCHED_FIFO 优先级 80 在两台控制器上均通过。四次测试的最大抖动为 0.063612 至 0.094448 ms，未出现漏周期、超限周期或常驻内存增长。[1]
| 控制器 | 负载 | 最大抖动 | 快照年龄 | 最大发布 | 漏周期 / 超限 |
|---|---|---|---|---|---|
| A | 无 | 0.085877 ms | 1.982421 ms | 0.096610 ms | 0 / 0 |
| B | 无 | 0.063612 ms | 9.277714 ms | 0.064073 ms | 0 / 0 |
| A | 有 | 0.094448 ms | 3.851881 ms | 0.081295 ms | 0 / 0 |
| B | 有 | 0.067025 ms | 9.068315 ms | 0.079147 ms | 0 / 0 |
失败的配置更能解释结果
标准或调优配置的最大抖动为 2.258783 至 3.662989 ms。仅使用 PREEMPT_RT 虽明显改善，但仍以 1.014743 和 1.340064 ms 未通过阈值。[1][2][3]
- 测量完整调度配置，而不是只记录内核名称。
- 把网络、日志和阻塞 I/O 移出周期线程。
- 失败数据应与最佳结果一起归档。
这些数据能证明什么，不能证明什么
结果支持继续开展 10 ms 试点研究，但不能证明最终验收、物理 I/O 时序、长期尾部延迟、数值正确性或功能安全适用性。[1]
尚未完成的项目包括带负载冷启动、100 ms 配置、同核服务竞争、后端新鲜度证据和端到端数值验证。[1]
下一轮测试应主动尝试破坏结果
- 在各类负载同时启动时进行冷启动。
- 让服务进程与运行时在同一核心竞争。
- 覆盖温升、日志轮换和网络重连的长时间运行。
- 除软件时间戳外测量物理 I/O。
- 公开原始数据、配置与失败结果。
常见问题
PREEMPT_RT 能保证确定性控制吗？
不能。硬件、驱动、优先级、负载和应用设计仍共同决定测量结果。
为什么使用 SCHED_FIFO？
它让高优先级控制线程抢占普通任务，但前提是线程工作量有界并受到监控。
这些结果等于生产批准吗？
不等于。这只是两台设备上的四次稳态试点测试，并明确列出了待验证项目。
资料来源与标准
- MCR Demo 1 steady-state 10 ms timing evidenceBootCtrl, 26 July 2026
- PREEMPT_RT theory of operationLinux kernel documentation
- sched(7): overview of CPU schedulingLinux man-pages project
- clock_nanosleep(2): high-resolution process sleepLinux man-pages project
- Cyclictest documentationLinux Foundation Real-Time Linux project
BootCtrl Engineering 于 2026年7月26日 最后核查本文技术论述与来源链接。所有产品表述均对照当前实现代码库；路线图工作不会被描述为已发布能力。
