jetson agx orin 实时内核 调度延时测试

jetson agx orin 是 nvidia 推出的计算平台，在自动驾驶领域得到广泛应用。

确定性执行是自动驾驶系统的基本要求，而任务调度的确定性是影响确定性执行的重要因素。

本文测试了 jetson agx orin 的调度延时，对比测试了两种情况：打实时内核补丁和不打实时内核补丁。

从测试结果来看，对于 rt 调度策略来说，打了实时内核补丁之后，最大调度延时在 70μs 以内；而不打实时内核补丁的话，最大调度延时在 1000μs 以上，差别还是比较明显的。

 

1 实时性和实时性指标

实时性说的是确定性，和响应快并不完全相等。

当听到实时性的时候，我们的第一反应就是实时性越好，响应就越快，特别是硬实时，我们的直观感受是硬实时的系统响应就没有延时，是立即响应。其实，实时性和响应快两个概念并不是相等的。实时性说的是确定性，比如在自动驾驶领域，车辆识别到障碍物的时候需要停止，从车辆识别到障碍物到车辆停止的时间是一个实时性指标。不同场景下的车辆对这个时间的要求是不一样的，对于高速场景下的乘用车而言，要求可能是微秒级别的，比如说 500μs；但是对于低速场景下的车辆，比如港口和矿山以及园区内的环卫车，这种要求可能就是毫秒级的，比如说 10ms。实时性说的是确定性，无论业务要求是 200μs，或者 1ms，甚至是 1min，只要系统满足时间指标的要求，那么就可以说是实时的。

 

实时性和实时性指标。

如上边所说，只要系统满足了业务的要求，不管是  200μs，或者 1ms，还是 1min，都可以说系统是实时的。但是实时性的指标是不一样的，200μs，1ms，1min 是实时性指标。

 

2 测试环境

测试机器是 nvidia Jetson AGX Orin 64GB Developer Kit，jetson 版本是 35.4.1。

 

确定内核是不是实时内核，可以通过 uname -a 来查看。如下图所示，显示 PREEMPT RT，说明是实时内核；机器默认的版本显示 PREEMPT，没有 RT，不是实时内核。

 

jetson agx orin 默认的版本是不包含实时内核补丁的。使用 uname -a 显示的信息如下，其中只有 PREEMPT，没有 RT，说明不包含实时内核补丁。

 

3 测试目标

测试调度延时的最大值，实时性关注的是最恶劣的情况，所以需要关注调度延时的最大值。

实时性只关注最大调度延时，如果有两个系统 a 和 b，a 系统的平均延时是 1ms，最大调度延时是 20ms；b 系统的平均调度延时是 5ms，最大调度延时是  10ms。那么可以说 b 系统的实时性比 a 系统好。

 

为了构造恶劣的情况，测试时使用 stress-ng 增加系统负载，命令行如下：

stress-ng --cpu 16 -m 16 -i 16 -S 16 --timeout 14400s &

--cpu 16:  启动 16 个 cpu 消耗型的线程

-m 16:  启动 16 个线程，模拟内存操作

-i 16:  启动 16 个线程，模拟 io 操作

-S 16: 启动 16 个线程，模拟 socket 操作

上述命令执行之后，平均负载和 cpu 使用情况如下，平均负载在 70 左右，每个核的 cpu 使用率都接近了 100%。

 

使用  cyclictest 工具测试调度延时，cyclictest 是专门用于测试调度延时的工具。

cyclictest -t 8 -D 2h --policy=fifo

-t 8: 启动 8 个线程

-D 2h: 测试时间 2 个小时

--policy: 指定调度策略

--priority: 指定线程优先级

测试 3 种调度策略，SCHED_FIFO，SCHED_RR，SCHED_NORMAL，优先级使用 cyclictest 设置的默认优先级。SCHED_NORMAL 是普通调度策略， SCHED_FIFO 和 SCHED_RR 是实时调度策略。在实际使用中，如果我们的业务对实时性要求比较高，那么需要将对应的线程的调度策略设置为实时调度策略。

本实验只测试了 SCHED_FIFO 调度策略下的调度延时。

 

4 测试结果

4.1 实时内核

 

4.2 非实时内核