2. 实时系统基础
在 PREEMPT RT Linux 实时控制工程中，理解“实时”二字的工程含义是后续所有设计决策的起点。很多人误以为“实时”就是“速度快”，但在实时系统语境下，实时指的是系统能够在确定的时间约束内对外部事件作出响应，而不是平均响应有多快。一个平均响应 1 毫秒但偶尔抖动到 200 毫秒的系统，在硬实时场景中可能完全不可用；而一个平均响应 5 毫秒但最坏响应稳定在 6 毫秒以内的系统，反而可能满足硬实时要求。因此，实时性的核心不是“快”，而是“可预测”和“有界”。
一、硬实时与软实时的本质区别
硬实时（Hard Real-Time）要求系统必须在截止时间（Deadline）之前完成响应，一旦超时，后果被视为系统失效，可能造成人身伤害、设备损毁或重大经济损失。例如工业机器人关节伺服控制、汽车安全气囊触发、航空电传飞控、医疗除颤器等。软实时（Soft Real-Time）则允许偶尔超时，超时只会导致服务质量下降，而不会造成灾难性后果，例如音视频播放、人机界面刷新、普通数据采集显示等。
两者之间还存在一种常见的中间形态——固实时（Firm Real-Time）：偶尔超时的结果虽然无灾难性后果，但该次计算结果已失去价值，例如高频交易撮合、某些视觉跟踪帧处理。工程上判断一个系统属于哪一类，关键看三个问题：超时的后果是什么？超时是否可接受？超时概率需要控制在什么量级？
判断口诀：看后果定类型，看概率定指标，看最坏值定设计。硬实时关注最坏情况（Worst-Case），软实时关注统计平均与用户体验。
二、实时性核心指标：延迟、抖动与确定性
实时系统的性能不能只用“快”来描述，而要用一组可量化的指标来刻画。最核心的三个指标是延迟、抖动和确定性。
- 延迟（Latency）：从事件发生到系统产生有效响应之间的时间。在 Linux 中通常拆分为中断延迟、调度延迟、任务执行时间等。中断延迟指硬件中断触发到中断服务程序（ISR）第一条指令执行的时间；调度延迟指唤醒一个高优先级任务到该任务真正获得 CPU 的时间。
- 抖动（Jitter）：同一周期性事件响应时间的波动范围，通常用最大值与最小值之差或标准差衡量。抖动是实时控制中最危险的敌人，因为它直接破坏控制环路的采样周期一致性。
- 确定性（Determinism）：系统在最坏情况下仍能满足时间约束的程度。确定性越高，最坏响应时间越接近典型响应时间，系统行为越可预测。
可以用一个简单的关系来理解：最坏响应时间 = 平均响应时间 + 抖动。硬实时设计必须保证最坏响应时间小于截止时间，因此降低抖动往往比降低平均延迟更重要。
三、从指标到工程：如何度量与验证
在 PREEMPT RT Linux 上，最常用的延迟度量工具是 cyclictest。它通过高精度定时器周期性唤醒线程，记录每次唤醒的实际时间与期望时间的偏差，从而统计最小、平均和最大延迟。下面是一个典型命令：
cyclictest -m -p 80 -n -i 1000 -l 100000 -h 400
# -m 锁定内存，-p 80 优先级，-i 1000 周期 1000us
# -l 100000 循环次数，-h 400 直方图上限 400us输出中的 Max 列就是最坏延迟，它直接决定系统能否满足硬实时截止时间。工程上通常要求连续运行数小时甚至数天，观察 Max 是否稳定。如果 Max 偶尔出现尖峰，需要结合 ftrace、trace-cmd 或 hwlatdetect 定位是硬件 SMI、BIOS 电源管理、驱动关中断还是调度器配置问题。
| 指标 | 含义 | 典型工具 | 硬实时要求 |
|---|---|---|---|
| 中断延迟 | 中断触发到 ISR 执行 | hwlatdetect、ftrace | 通常 < 50 μs |
| 调度延迟 | 唤醒到任务获得 CPU | cyclictest | 通常 < 100 μs |
| 抖动 | 响应时间波动范围 | cyclictest 直方图 | 越小越好，需有界 |
| 最坏响应时间 | Max 延迟 | cyclictest -h | 必须小于 Deadline |
四、常见应用场景与误区复盘
硬实时场景包括：工业运动控制（EtherCAT 周期 250 μs～1 ms）、机器人伺服、数控机床、汽车 ABS/ESP、航空飞控、电力继电保护。软实时场景包括：视频会议、在线游戏、桌面交互、普通 SCADA 画面刷新。固实时场景包括：高频交易、雷达信号处理、机器视觉缺陷检测。
常见误区一：把“平均延迟低”当成“实时性好”。硬实时看的是最坏值，平均值再低，一次超时也可能导致事故。
常见误区二：认为 PREEMPT RT 打上补丁就自动硬实时。实际上还需要 CPU 隔离、中断亲和、关闭电源管理、锁定内存、合理优先级等一系列配置。
常见误区三：忽略抖动来源。缓存未命中、TLB 抖动、SMI、NUMA 跨节点访问、频率调节都会引入不可预测延迟。
工程建议：先明确截止时间和可接受超时概率，再用 cyclictest 做基线测量，最后通过隔离 CPU、设置实时优先级、禁用 C-States 和频率调节来压缩最坏延迟。设计时预留 2～3 倍余量，不要把最坏延迟压到截止时间边缘。
总结来说，硬实时与软实时的分界线在于超时后果，而延迟、抖动和确定性是描述实时性的三把标尺。在 PREEMPT RT Linux 工程中，一切优化都应围绕“降低最坏延迟、压缩抖动、提高确定性”展开，而不是单纯追求平均速度。