工具/软件：
4.2.3.1. 基于计时器的 Applications μ s
例如、为了进行质量保证、您需要每100us 从传感器进行一次测量。 因此、我们的应用将每100us 唤醒一个任务、以便进行该测量、然后再将其发送到主控制器。 这是一个基于计时器的任务、我们需要确保内核具有足够快的周期性中断生成、以确保内核可以切换到我们的任务、在100us 的最后期限采集样本。
为了模拟此类工作负载、我们可以使用 stress-ng 等工具生成应用程序可能遇到的各种背景负载。
stress-ng–cpu-method=all -c20 &
然后、我们可以监控应用的性能、或使用另一个工具 (如 cyclictest)来测量 CPU 遇到的上下文切换延迟。
Cyclictest 是一个由实时内核开发人员维护的简单程序、用于在开发下一个版本的 Linux 内核时检测任何错误或延迟尖峰。 有很多选项可以设置、但在此示例中、我们将在所有 CPU 内核上运行 cyclictest、其优先级为80、持续5小时。
Cyclictest -m -Sp80 -D5h -H400 -i200 -M
...
#总计：108000000 10799945 107999881 107999811
#最小延迟：00003 00004 00003 00003 #平均延迟：00005 00005 00005 00005 #
最大延迟：00029 00033 00034 00037
在这里、我们可以看到每个 CPU 平均花费5 μ s、但他们最多花费29 μ s、33 μ s、34 μ s 和37 μ s 从后台 stress-ng 任务切换到测量上下文切换的 cyclictest 任务。 但如果您的应用程序不仅仅消耗 CPU 周期、那么这可能无关紧要。
根据用例、与仅运行 CPU 应力函数(例如对存储器管理系统施加压力的函数)相比、运行不同或更多应力算法可能更合适。 有关 stress-ng 中这些函数的更多信息和完整列表、可以在以下项目的源代码中找到： https://github.com/ColinIanKing/stress-ng
4.2.3.2. 基于驱动程序(以太网)的 Interrupts
稍后我们将看到、在为实时内核中的 CPU 提供 IO 或硬中断服务方面做了大量工作。 虽然这些中断处理程序的很大一部分已卸载到可使其进入睡眠状态的线程中断上、但这些较小的硬中断不会完全透明、并会继续降低性能。
一种很好的演示方法是使用 iperf3工具生成大量以太网流量。
在连接到我们的嵌入式设备的主机上、我们可以运行以下命令来创建一个服务器、以侦听传入的网络流量
iperf3 -s
接下来、在我们的嵌入式器件上、我们可以发出命令向服务器来回发送以太网流量、从而为 CPU 产生大量硬中断、以便为传入的数据包提供服务
iperf3 -c 10.10.10.1 -p 7575 -BIDIR
从后台开始、我们可以开始监控应用程序、或再次使用 Cyclictest 来表明最大延迟已增加、而根据您的用例、可能甚至超过我们对应用的要求。
我使用版本为10.01的 AM6442芯片。 对于基于 Debian 的 RTOS 上的中断延迟测试、除了上述两种方法外、是否还有其他方法来测量中断延迟？ 我想测试其中断延迟、以便将其实时性能与其他系统进行比较。
