测量延迟
在本地开发机上编译适当的内核镜像、文件系统、引导加载程序和其他必要文件后，开始进行延迟测量。测试使用的两种内核都按照前面在负载生成中所述进行了配置。一旦所有文件都烧录到SD卡并成功启动系统后，在进行任何测试之前，系统将出现3分钟的空闲。在此期间，内核有时间初始化内部数据结构，如随机数生成器，以完全完成启动过程。这样，任何内部内核初始化都不会影响测量结果。
在这个过程之后，内核已经准备好进行实际的测量了，因为昉·星光 2包含DVFS驱动程序，在测试中可以改变CPU的频率。要获得精度测试结果，请将CPU频率设置为最高值（1.5 GHz）。
-
设置最高的CPU频率：
echo performance > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
-
设置不同的负载（CPU、OS、Memory或Storage）：
cpu: stress-ng --matrix 4
os:stress-ng --set 4
memory: stress-ng --vm 4
storage:stress-ng --dir 4
-
运行cyclitest：
cyclictest -m -S -p 99 -i 200 -q -D 10m -H 200
（cyclictest参数细节可以看延时测量一节）
每次测试延迟持续10分钟，产生大约120万个延迟样本。使用主线和PREEMPT_RT补丁内核对每个负载类别重复相同的过程，没有遇到任何问题。全部加起来，一共执行了10种不同的测量组合。
测量延时结果中显示了测试结果数据。使用表格格式在不同类别和内核之间进行比较更容易。最重要的是，该表包含了每个测量的绝对最大观测延迟。其他重要的指标是平均延迟和各自的标准偏差。此外，为了保证完整性，还给出了最小的观察延迟。循环测试工具报告测量到的实际时钟分辨率为1µs，所以提出的所有计算和测量都是四舍五入到最近的微秒。
stdev是延迟的标准偏差。它反映了延迟的抖动。stdev的值越低，实时系统就越好。附录B中列出了计算方法和一个实例。
| 压力 | 实时 | 主线 | ||||||
|---|---|---|---|---|---|---|---|---|
| 平均值（µs） | Stdev（µs） | 最小值（µs） | 最大值（µs） | 平均值（µs） | Stdev（µs） | 最小值（µs） | 最大值（µs） | |
| Idle | 6 | 2 | 5 | 37 | 8 | 4 | 6 | 66 |
| CPU | 8 | 4 | 6 | 39 | 10 | 6 | 6 | 88 |
| OS | 9 | 8 | 6 | 46 | 20 | 16 | 6 | 9162 |
| Mem | 12 | 6 | 6 | 95 | 12 | 14 | 6 | 14125 |
| Storage | 10 | 7 | 7 | 49 | 16 | 14 | 7 | 3025 |
就主线内核而言，idle条件下测得的最大延迟最低，这在意料之中。此外，在这种特殊情况下，平均延迟和标准偏差也最小。当系统引入 CPU 负载时，会导致延迟上升，但最大延迟保持在 100 µs 以下。然而，在其他各种负载下，延迟时间明显延长。
在主线内核中进行的操作系统和内存压力测试似乎比实时内核要差得多。在这种类型的负载下，最大延迟以毫秒计，并且平均延迟与实时系统相比也要高得多，标准偏差较显著。
对于实时内核，在所有不同的类别中，观察到的延迟彼此非常相似。除误差类别外，所有测量的最大延迟都远低于200µs。此外，在整个测试过程中，观察到的标准偏差始终很小，这表明大多数经历的延迟都接近于平均数字。因此，向系统应用任何选定的负载都不会对系统的响应造成太大影响。