第三篇：实时系统，快不等于准时

在工业控制、汽车电子以及内核开发领域“实时”Real-Time经常被外行误解为“快”。但作为每天和中断、调度器打交道的内核工程师我们知道实时和绝对的速度没有必然关系。实时的本质是“在可预期的边界内绝对准时”。如果一个系统必须在 1 毫秒内响应某个硬件信号哪怕你的系统平均响应时间是 1 微秒只要有万分之一的概率出现了一次 1.001 毫秒的延迟在硬实时Hard Real-Time领域这个系统就是失败的甚至可能导致灾难性的后果比如汽车安全气囊未及时弹出。为了解构“实时”我们需要把它的三个核心支柱——确定性、低延迟、低抖动彻底剥离并理清它们之间的内在逻辑。一、 确定性Determinism实时的灵魂确定性是实时系统的终极追求。它是指给定相同的系统状态和外部输入系统产生响应所需的时间边界是完全可预测、可数学证明的。非确定性标准 Linux你无法预知下一个kmalloc会花费多长时间。它可能直接从 Slab 分配器拿到内存微秒级也可能触发内存回收甚至内存紧缩毫秒级。这种“碰运气”的代码就是非确定性的。确定性实时内核在实时内核中所有的动态行为都有时间上限。例如最坏情况下的锁等待时间、最坏情况下的任务切换时间。实时系统不在乎你的代码跑得有多快它在乎的是 T_worst-case T_deadline最坏情况下的执行时间绝对不能超过截止期限。二、 低延迟Low Latency响应的距离延迟是指从“事件触发”到“响应完成”之间流逝的时间Time Elapsed。在内核级我们通常关注中断延迟和调度延迟总延迟} 中断响应延迟 (HardIRQ Latency)} 调度线程唤醒延迟 (Scheduling Latency)低延迟并不等于实时一个普通的 Android 手机在玩游戏时触控延迟可以做到非常低比如$15\text{ ms}$。但这只是“平均延迟低”。如果在系统高载如背景正在安装 App时某一次触控延迟突然飙升到200ms用户只会觉得“卡了一下”但这表明它不具备实时性。实时对延迟的要求实时系统通常也追求低延迟因为延迟越低留给计算单元CPU处理业务逻辑的时间就越充裕。但实时更强调的是延迟的上限Bounded Latency。三、 低抖动Low Jitter稳定的基石抖动是指在多次重复的事件响应中延迟时间的变化幅度和波动范围Variance / Fluctuation。我们可以用打靶来打个比方延迟是子弹偏离靶心的距离。抖动是你多次射击时弹着点的分散程度。假设一个音频播放线程需要每隔刚好10 ms向硬件 FIFO 喂一次数据情况 A每次喂数据的时间点分别是10.01ms、9.99ms、10.02ms、9.98ms。评估平均延迟适中抖动极小在0.02ms内。这是一个极好的实时表现音频听起来会非常丝滑。情况 B时间点变成了2ms、18 ms、1ms、19ms。评估虽然算下来平均延迟也是 10ms但抖动高达 9ms。这会导致音频缓冲区要么瞬间溢出要么瞬间干涸Buffer Underflow出现严重的爆音和断音。实时内核的核心工作就是通过消除内核隐式锁、中断线程化等手段把这层“抖动”削平让延迟曲线变成一条几乎平直的线。四、 三者的黄金关系如何构建“实时”这三个概念并不是孤立的它们构成了实时系统的技术闭环低延迟缩短了时间线的绝对长度为系统争取了更多的容错空间。低抖动抹平了由于系统负载变化、垃圾回收、锁竞争导致的不可控时间波动。当你成功把延迟压低并且把抖动控制在极小的范围内时你就获得了高确定性。拥有了确定性整个系统才真正算得上是实时系统。从 Android/Linux 工程师的角度看现状在现代复杂的 SoCMTK 平台上实现硬实时变得越来越难。因为除了软件层面的普通 Linux 内核不实时之外硬件上的多核 Cache 一致性同步、DRAM 刷新机制、DVFS动态电压频率调节带来的 CPU 降频都会引入巨大的抖动。所以现在的架构设计往往会走向两个极端软实时Soft Real-Time在应用层/系统层通过 Android 的SCHED_FIFO实时调度策略、提升大核亲和性CPU Affinity、或者靠前文提到的PREEMPT_RT补丁尽量把抖动压到微秒级用于音频、车载仪表盘显示等。硬实时Hard Real-Time如果涉及底层的电机控制、激光雷达测距工程师通常会直接抛弃 Linux 核心把这部分核心控制逻辑下放到 SoC 内部挂载的专用Cortex-M / DSP 硬实时核上跑 RTOS如 FreeRTOS再通过 IPI核间中断与跑 Android 的 Cortex-A 主核通信。