跳过正文

VxWorks与RTLinux的性能对比分析

VxWorks RTLinux Performance
目录
APP - 这篇文章属于一个选集。
§ 13: 本文

作者:Benjamin Ip | COMS W4995-2,嵌入式系统语言,哥伦比亚大学计算机科学系,纽约

摘要
#

本文比较并评估了两种实时操作系统(RTOS)的适用性:商业可用的VxWorks和公开可用的RTLinux。在保持硬件不变并使用不同的测量方法的前提下,我们测量了操作系统上下文切换、中断处理、对象同步和消息传递过程中产生的开销。我们还检验了它们在处理优先级反转问题方面的有效性。

我们的研究结果表明,VxWorks和RTLinux都提供了良好的原始性能。

然而,VxWorks更具可预测性和确定性,因此更适合作为开发和运行软硬实时应用程序的操作系统平台。

引言
#

VxWorks概述
#

VxWorks是嵌入式行业迄今为止应用最广泛的商业RTOS。它由WindRiver开发,旨在设计一个具有快速、高效和确定性上下文切换的操作系统。其Wind微内核可以支持抢占式和轮询调度策略,以及具有最多256个优先级级别的无限数量的任务。VxWorks还以其丰富的工具链和运行时库而闻名,这些工具链和运行时库显著减少了应用程序开发的时间。尽管VxWorks具有丰富的功能,但其许可费用很高。

RTLinux概述
#

与Linux不同,RTLinux提供硬实时功能。它具有混合内核架构,小型实时内核与作为最低优先级任务运行的Linux内核共存。这种组合使RTLinux能够提供高度优化的分时服务,同时并行提供实时、可预测和低延迟的执行。除了这一独特功能外,RTLinux还可供公众免费使用1。随着越来越多的开发工具面向RTLinux,它将成为嵌入式市场的主导者。

  • 1 RTLinux由Finite State Machine发布。

性能指标
#

我们的项目目标是通过测量以下关键指标来研究这两种操作系统的性能分析。

上下文切换
#

这两种RTOS都设计为支持多任务处理。此功能对于经常使用多个异步执行任务实现的实时应用程序非常重要。在任务调度期间,需要上下文切换来挂起一个任务并立即恢复另一个任务。因此,分析平均上下文切换延迟对于测量操作系统响应性至关重要。

优先级反转
#

当高优先级任务被阻塞,等待低优先级任务释放高优先级任务共享的资源时,就会发生优先级反转。优先级反转是实时系统中的一个严重问题,因为它通常会导致死锁。这两种RTOS都包含自己的优先级继承协议,项目目标之一是检验这些协议的有效性。

中断延迟
#

中断延迟定义为中断阻塞时间的总和,在此期间,内核正在等待响应中断、保存任务上下文、确定中断源和调用中断处理程序。对于特定的中断,延迟还包括其他嵌套中断处理程序的执行时间。由于大多数嵌入式系统都是中断驱动的,因此低中断延迟将显著提高系统吞吐量。

同步
#

VxWorks和RTLinux提供了一整套同步方法,以允许对共享资源的独占访问。获取和释放信号量以保护共享对象会产生一定的惩罚。这种惩罚通常与将请求的任务添加到对象锁队列和从中删除有关。因此,测量同步开销是确定实时操作系统可行性的另一种方法。

进程间通信
#

现代实时应用程序构建为一组独立的协作任务。除了高速信号量外,VxWorks和RTLinux还提供消息队列作为更高级别的同步机制,以允许协作任务相互通信。由于实现复杂性,使用此服务会产生最大的延迟,因此是操作系统研究的关键指标。

测量过程
#

测量上述指标需要一定程度的分辨率、准确性和粒度。在我们的整个项目中,硬件和软件逻辑分析仪都被用于捕获和记录测量样本。我们强调使用硬件逻辑分析仪,因为它提供最佳分辨率、对实时代码的最小干扰,更重要的是,它是平台独立的。在大多数测试用例中,软件分析仪用于验证。我们还开发了小型固件代码来设置内存映射和中断向量表、调整系统时钟以及禁用硬件缓存。为初始化任务、信号量和消息队列而编写的所有测试函数和系统调用均符合POSIX标准。最后,每个测试都以25个样本的样本量进行测量,以确保收集的数据在统计上可靠。

测试环境
#

我们的测试在VxWorks 5.4版本和RTLinux 3.0版本下进行。我们在制造商提供的评估板及其板级支持包上执行了所有测试。这些显著减少了配置硬件所花费的开发时间。

相关工作
#

操作系统性能分析长期以来一直是研究小组感兴趣的课题。Levine [1]及其同事展示了他们在实时CORBA2架构的上下文切换时间和优先级反转协议延迟方面的基准测试结果。Levine [1]检测和观察优先级反转的方法很复杂。Obenland [4]的文章解释了一种创建优先级反转场景的简单方法,将在下一节中介绍。

  • 2 通用对象请求代理体系结构

Sohal [3]采用分析和经验方法来测量实时操作系统中断延迟的不同阶段。由于时间限制,我们仅选择了Sohal的一个通常揭示中断处理性能的中断测试。然而,我们没有应用Sun [4]的方法来测量中断延迟,因为Linux中断机制与RTLinux的实现方式截然不同(没有区分中断服务例程的顶部和底部)。

我们还从Obenland [2]的经验中了解到,在执行任何IPC测试之前,消息队列应没有挂起的消息,并且接收任务必须被阻塞,等待消息。

在Stewards [4]的论文中,他花费了大量时间回顾和解释产生不同粒度结果的各种测量技术。我们确信Stewards [4]认为硬件逻辑分析仪优于项目中的其他测量工具和技术。

测试方法和实验结果
#

我们修改了上一节中引用的一些测试方法,以获得公平和准确的结果。本节介绍了测量结果以及我们用于测试不同指标的方法。

上下文切换
#

我们配置了两种RTOS,以使用轮询调度策略来确定上下文切换时间。图1显示,使用轮询策略,我们只需要创建两个任务,并让调度程序交替执行它们,而无需对其进行优先级排序。

上下文切换测试设置
图1:上下文切换测试设置

被测的两个任务具有相同的功能;每个任务都包含一个无限空循环,以避免额外的计算。表1显示了以微秒为单位测量的平均(和标准偏差)上下文切换时间。

上下文切换时间测量结果
表1:上下文切换时间测量结果

在VxWorks上测量的上下文切换时间始终很低,标准偏差为0.04。相反,RTLinux上下文切换时间比VxWorks高18%,并且不如VxWorks一致(标准偏差为0.6)。因此,VxWorks的上下文切换时间更具确定性。RTLinux的较低分数似乎表明,并行运行实时和非实时任务可能不是嵌入式产品最可行的解决方案。

优先级反转
#

我们通过以低、中和高优先级运行三个任务来创建优先级反转场景,其中低优先级和高优先级任务竞争相同的资源。以下是从软件分析仪捕获的优先级反转(黄色箭头)的发生情况。tCyclicTask、tWorkTask和tSlowTask对应于具有高、中和低优先级的任务。

使用软件分析仪测量优先级反转
图2:使用软件分析仪测量优先级反转

我们测量了tCyclicTask请求资源和tSlowTask释放资源之间的几个时间,结果如表2所示。

优先级反转测量结果
表2:优先级反转测量结果

RTOS的一个重要特征是可预测性。尽管RTLinux解决优先级反转问题的时间较短,但这两个数字似乎都在可接受的范围内。这表明两种RTOS都实现了有效的优先级继承协议,以确保满足关键期限。

中断延迟
#

在本实验中,我们配置了周期为50 MHz的MPC8260硬件计时器,以每20 s生成一次计时器中断。更新系统滴答计数的中断服务例程被挂接到中断向量表。我们使用硬件逻辑分析仪测量计时器中断的断言和ISR的执行之间的时间(图3)。

中断延迟测试设置
图3:中断延迟测试设置

请注意,所有其他系统中断都被禁用,因此我们的测量结果不受嵌套中断的影响。表3记录了两个系统的平均中断延迟和标准偏差。

中断延迟测量结果
表3:中断延迟测量结果

VxWorks的中断延迟(35%)比RTLinux低得多,这并不奇怪。

传统Linux以具有高中断延迟而闻名。似乎即使RTLinux添加了实时功能,它仍然表现出一些非实时行为。

同步
#

在我们的测试中,我们仅关注测量两个系统中获取二进制信号量的时间。为了测量信号量开销,我们首先创建并初始化信号量本身,使其不可用。

二进制信号量测试设置
图4:二进制信号量测试设置

然后,我们生成两个任务,分别按精确顺序释放和获取信号量。最后,我们测量了任务调用系统调用以获取信号量的时间(图4)。由于第一个任务应在第二个任务执行之前释放信号量,因此该任务不应被阻塞等待。表4显示了VxWorks和RTLinux成功获取信号量的平均开销。

二进制信号量获取测量结果
表4:二进制信号量获取测量结果

这些数字表明,RTLinux获取二进制信号量的时间比VxWorks稍长。

进程间通信
#

此测试旨在测量任务通过消息队列向另一个任务发送消息所需的通信延迟,如图5所示。

消息队列测试设置
图5:消息队列测试设置

我们通过创建和激活(或打开)消息队列来开始此测试。接下来,我们生成一个调用消息接收函数的接收任务。接收系统调用会阻塞接收任务并将其置于等待状态(因为消息队列为空)。当接收任务正在等待消息时,我们生成一个发送任务,以通过同一消息队列发送消息。表5给出了发送任务调用消息发送函数和接收任务接收消息通知之间的时间。

消息队列测量结果
表5:消息队列测量结果

在消息发送/接收延迟方面,RTLinux以微弱优势获得了比VxWorks更好的分数。如前所述,这些数字可能会因IPC实现(可以使用共享内存实现IPC)而有很大差异。

结论和未来工作
#

在这个项目中,我们测量了几个实时操作系统的关键指标,以评估VxWorks和RTLinux的性能。本文介绍的结果大致符合这两种操作系统的特性。我们的总体分析表明,这两种操作系统都适用于实时应用程序。特别是,VxWorks更具确定性和可预测性。由于时间限制和资源有限,我们只能专注于研究操作系统的核心——揭示真实系统行为的内核级性能。现代实时操作系统通常与强大的运行时库、可扩展的网络组件和灵活的文件系统打包在一起。涵盖这些方面的广泛测试将为我们提供性能与成本方面的全面结果。因此,如果没有详尽的比较,很难得出哪种操作系统优于另一种操作系统的结论。

参考文献
#

  • [1] D. Levine, S. Flores-Gaitan, C. D. Dill, and D. C. Schmidt, “Measuring OS Support for Real-Time CORBA ORBs”, in 4th IEEE International Workshop on Object-oriented Real-Time Dependable Systems 00’, Santa Babara, California, Jan. 27-29.
  • [2] K. Obenland, “Real-Time Performance of Standards Based Commercial Operating Systems”
  • [3] V. Sohal, “How To Really Measure Real- Time”, Embedded System Conference, Spring 2001
  • [4] Jun Sun, ”Interrupt Latency”, Monta Vista Software, https://www.mvista.com/realtime/latency/
  • [5] D. Stewart, “Measuring Execution Time and Real-Time Performance”, Embedded System Conference, Spring 2001
  • [6] Real Time magazine, “Evaluation Report Definition”, https://www.realtime-info.de/, March 1999
  • [7] R. Appleton, “Understanding a Context Switch Benchmark”, Jan. 1997
  • [8] V. Yodaiken, “An Introduction to Real- Time Linux”
  • [9] Victor Yodaiken, “The RTLunix Approach to Hard Real-Time”, Oct. 1997
  • [10] P. Wilshire, “Installing RTLinux”, 2000
  • [11] WindRiver Systems Inc, Tornado User’s Guide, Alameda,CA: WindRiver Systems, Inc, 1999
  • [12] WindRiver Systems Inc, VxWorks Programmer’s Guide, Alameda,CA: WindRiver Systems, Inc, 1999

原文地址: Performance Analysis of VxWorks and RTLinux

APP - 这篇文章属于一个选集。
§ 13: 本文

相关文章

基于VxWorks的视频采集系统的设计与实现
VxWorks BT848
在Arm Cortex-R82上运行VxWorks
VxWorks Arm Cortex R82
VxWorks设备驱动开发详解
VxWorks Device Driver