强实时应用环境下VxWorks, Linux, RTAI和Xenomai系统的性能比较.doc

课程：嵌入式系统 作业：文献翻译 电工理论与新技术_130501_徐浩泽_YS1310501037 如有需要可提供电子版强实时应用环境下VxWorks, Linux, RTAI和Xenomai系统的性能比较A. Barbalace, A. Luchetta, G. Manduchi, M. Moro, A. Soppelsa, and C. Taliercio摘要：使用配置MPC7455 PowerPC处理器的VMEbus MVME5500 开发板对Wind River VxWorks, Linux, RTAI和 Xenomai四种不同操作系统进行性能测试。以一个时间实时应用的框架为例对中断延迟，重调度和程序间通信时间进行比较。对Gb以太网通信的性能测试也在目标板上进行。为达成此目的，我们将Linux IP stack 和 RTnet，Xenomai和 RTAI的一种开源强实时通信协议移植到所用的系统中。测试结果显示被测的开源软件适用于强实时应用环境。关键词：实时系统，Linux, RTAI, Xenomai, ADEOS, RTnet, VxWorks, PowerPC.1. 简介自1998年以来，实时反馈控制系统已经被广泛应用于RFX-mod 实验。RFX-mod是一个用于研究磁约束热核聚变的环形装置，坐落于意大利的帕多瓦。目前在使用的有7个控制单元，每个单元都包含一个使用摩托罗拉MVME5500单板机和其他ADC/DAC转换器以及其他数字接口板的模组箱。控制单元组成控制网络，数据在各单元间进行实时交换。一个提供了通用功能以及数据处理和通信功能的软件框架已经在VxWorks平台上搭建起来。VxWorks被广泛应用于物理学研究的原因包括：提供了一个集成开发环境，简化了开发过程。程序在被下载到目标系统之前可以在主系统中做开发和仿真。提供了一个强大的多任务化环境，任务有固定的优先级，可以通过一组丰富的进程间通信（IPC）机制进行通信。VxWorks的软件模式与UNIX非常相似，尤其是I/O和网络，对于熟练使用UNIX的开发者来说，编程变得非常简单。但是，近年来，Linux系统的蓬勃发展使得将其应用于实时控制系统变得极富吸引力。但是对于数据采集，或者更广泛的说，对于所有不需要严格的时间确定性的任务，Linux已经被应用于科学实验当中。但是Linux的一些特性使其不能被直接应用于实时应用，例如：动态优先级。使用随时变动的优先级是解决分时的一个好方法，但是可能会使一个紧急事件无法足够快的拿到CPU权限。分页。可能会引入额外的延迟除非将页在内存中锁定。内存管理单元的重新映射。用户程序占用CPU时重新映射进入内存管理单元（MMU）的页面表会减缓上下文切换。粗粒度的同步。由于内核为非先发式，有时系统无法响应冗长的内核操作时。最近的2.6版本Linux内核为以上问题提供了解决方案。事实上将固定优先级与过程子集想联系是可能的，这一版本的内核通过精确定义不可中断的程序段和自旋锁保护而不是禁止中断已经被定制为先发制人的了。此外Linux kernel 2.6提供了一个新的O调度的实现。考虑到交互可以被禁止，而且，给定了级别范围，优先级可以被固定，我们可以将Linux暂时考虑成一个软实时操作系统并因此可以被应用于许多可以忍受偶尔的系统响应延迟的场合。但是Linux 2.6 仍然不适用于聚变反应反馈控制这种强实时场合，在这种情况下，事实上,不可预测的反应时间可能恶化控制的质量，或者更糟糕的是，导致不可恢复的不稳定性。然而，在引用文献4和5中，借助脉冲性质的实验，Linux已经被成功的应用到了强实时场合。在这种情况下，大多数的时间过程控制系统不需要运行在实时模式。只有在等离子放电这一在大多数现有聚变实验中只持续数秒的过程中才需要实时控制。因此当需要进行实时操作时禁止中断是可行的，这实现了一个循环周期12s的整体抖动。在禁用中断时,尤其要注意：代码和数据必须被锁定到内存中来防止页面错误，软件不能依赖系统服务控制I/O。因此除了轮询输入数据和写输出数据，控制代码不能与外部环境通信，对于一个固定的迭代次数，使用预配置的地址窗口。这个解决方案尽管在特定的应用程序成功，仍然有各种各样的原因使其不能被认为是一个结论，最主要的是因为在下一代聚变装置中，控制系统被期望用于控制长时间放电，或者准稳态过程。2. Linux 系统的实时扩展我们主要希望能找到一种方法，给Linux增加一些定义新的实时任务的可能性，从而保证在它们已经准备好运行时，能在一个确定的时间内获得控制。这个特性是由两个开源Linux扩展: RTAI和Xenomai提供。RTAI和Xenomai大多数概念相同(他们源自同一个项目)，都代表而不是代替了Linux，一个结合Linux工作的额外的组件，处理的实时任务的调度,让Linux提供所有剩余的功能。但是，为了与Linux配合，额外的组件和Linux共享底层硬件是必要的。通过使用ADEOS超微内核作为硬件功能的代理，RTAI 和Xenomai都实现了这种共享。特别的，ADEOS通常掌控硬件中断，并为其他组件传播通知序列。所以，Linux和RTAI（或Xenomai）代表ADEOS域，并由超微内核作为管线从逻辑上组织起来。声明在流水线前端的组件将先接收到中断通知，然后可以决定ADEOS是否让它们沿着域管传播。在RTAI（或Xenomai）位于管道前端因而优先于Linux的情况下，可以忽略Linux的实际运行，确定响应时间。如 图 1 所示这个组织在Xenomai中已经完全实现。图 1 Xenomai分层图 2 RTAI的分层如 图 2 所示RTAI有稍微不同的组织形式，与Xenomai让ADEOS掌控所有的中断源不同的是，RTAI拦截它们，使用ADEOS将那些RTAI不感兴趣的中断通知送给Linux（也就是，中断不影响实时时序）。这样混合过程的目的是提高性能，因为在这种情况下，如果中断是要唤醒一个实时任务，就避免了由ADEOS管理中断的开销。RTAI和Xenomai都有一个活跃的开发者社区，都可以作为一个VxWorks的开源替代。为了评估是否适合我们的目标，我们进行了一组测量比较了Linux，RTAI，Xenomai和VxWorks的性能。我们使用PowerPC架构，使用摩托罗拉MVME5500单板机，这个选择的原因是PowerPC构架在执行浮点运算时性能要优于x86构架。此外，在开发RFX-mod的实时控制系统时，我们得到一个非常有价值的经验：使用PowerPC系列处理器提供的向量构架组件（(AltiVec）进行并行浮点运行。但是，RTAI还没有往PowerPC构架进行移植，ADEOS也有程序错误而无法在我们的平台上应用。因此，为了在MVME5500单板机上使用RTAI和Xenomai（两者都在ADEOS分层）我们先开发了一个补丁集。3. MVME5500平台上LINUX，ADEOS，RTAI和XENOMAI的移植为了将Linux, ADEOS, RTAI和 Xenomai移植到目标板上，我们开发了一些补丁。为了安装Linux，Vanilla Linux Kernel v 2.6.14使用了一个从摩托罗拉公司获得的补丁。但是我们必须开发一个附加的补丁修正一些VME数据存取中的错误。超微内核ADEOS已经被移植到PowerPC架构，但是有一个程序错误使其不能被应用于使用Galileo GT-64260系统控制器的所有平台。我们在一个新的补丁中已经修正了这个错误。安装Xenomai时并未做任何改动，因为已经有PowerPC使用的版本，而且不需要特定板支持。Xenomai已经在AEDOS完全分层。RTAI没有PowerPC可用的版本，所以需要进一步的开发。最后，RTnet不需要额外的开发。ADEOS和RTAI两个系统开发的补丁已经被集成在官方的配置中。在RFX-mod官网上可以得到MVME5500板的所有Linux补丁。由于目标板是无盘的，系统引导首先由厂商提供的引导装载程序Motload完成。Motload使用普通文件传送协议(TFTP)从服务器下载内核。Linux使用网络文件系统(NFS)进行文件输入/输出。4. 性能测定为了评估性能，我们重点关注两个特性：中断延迟和延期时间。我们使用一个测试程序，acqloop，通过VME总线从ADC获得64个cannel产生一个输出到DAC板，对应于获得的第一个信号。虽然很简单,这个程序可以测试我们感兴趣的特性，因为当一组新的数字化数据已经准备好后ADC会产生一个中断。通过用示波器测量一个输入信号和系统的输出间的延迟，我们可以对系统的总体性能进行非扰乱性的测量，测定中断延迟和延迟时间的不同。整体延迟中的其他部分实际上是对VME I/O的访问引起的，在所有被测系统中可以认为是相同的。最后，我们考虑网络实时通信，因为大多数聚变装置的控制系统都涉及实时通信。RTAI和Xenomai都依靠Linux IP堆栈实现网络通信。因此我们首先扩展我们的测试程序acqloop，通过以太网连接和使用UDP协议在另一块板上生成输出信号，对VxWorks和Linux的IP堆栈性能进行了比较。我们对UDP协议感兴趣是因为它正在被现有的控制系统RFX-mod用于实时通信。然后我们考虑用一个开源项目RTnet，实现实时网络通信。RTnet实现了一种新的IP堆栈 (对于UDP)，非确定性的原因被精确的避免了。特别的，为了避免内存动态分配，数据包的内存分配由预分配所有需要提前的缓冲区实现。RTAI和Xenomai都可以使用RTnet。在第一轮测试中，我们关注被测系统中断延迟时间的差别。该情况下，acqloop首先安装一个中断服务程序(ISR)，直接读取ADC数据寄存器并写入DAC（通过VME）。对于VxWorks (v 5.5.1) acqloop为一个C函数实现，然后由shell调用，所有代码运行在本机的内核模式。其他系统，这段代码集成为Linux模块，因为它必须在内核模式执行。整个测量延迟是由于完成以下工作所需的时间组成：1) ADC板用于AD转换；2) 控制板上的VME芯片用于检测VME中断,并将其传播到系统控制器；3) 操作系统(OS)来处理中断和调用副ISR；4) ISR从VME读ADC数据；5) ISR向DAC写输出值；6) DAC转换器输出相应的电压值以上各段时间，只有第三段依靠操作系统实现。因此，被测系统的不同的测量延迟突出表现中断延迟的差异。测得的时间如 图 3 所示图 3无重调度的测量延迟和抖动整体性能数据是相似的，最快的(VxWorks) 和最慢的 (Xenomai)约有5%的差别。进一步分析表明RTAI和Xenomai的差异是因为在Xenomai中，中断总是首先被调度进入超微内核，这就Linux而言引入一个小的开销。相反的，RTAI在管理中断时旁路了ADEOS，只有在中断要传播到另一个域（Linux）时才依赖ADEOS。值得注意的是RTAI的性能和VxWorks非常接近，而且，抖动显然更小。在第二轮测试中，我们改变了acqloop程序，输出不直接由中断服务程序，而是由ISR设定的另一个等待信号量的内核任务写。测试结果如 图 4 所示，每个条形图的第二个部分代表重调度时间。图 4有重调度的测量延迟和抖动Linux的性能不管是延迟还是抖动都令人惊喜，但是该测试结果仅表示系统不加载的情况下，当工作量增加时会很快减少。相对地，其他系统的性能测试结果被证明受工作负载的影响非常小，除非在高中断率的情况下。VxWorks的性能和RTAI又非常接近，特别地，RTAI对执行本地实时任务一个非常高效的调度器。在最后一轮测试中我们考虑了网络通信，在这种情况下，等待信号量的进程不直接向DAC写输出，而是向另一块写DAC的MVME5500板发送一个包含所有获得样本数据的UDP数据包，UDP数据包的大小大约256字节（为了防止丢包，一些额外的字节用于UDP数据包时间标记）。有网络通信的测量延迟如 图 5 所示：图 5有实时网络通信的测量延迟本次性能比较中，Linux使用本地IP堆栈，RTAI和Xenomai都使用RTnet，VxWorks使用本地IP堆栈。值得注意的是VxWorks的网络通信性能是较差的，事实上在RFX-mod上使用VxWorks最新的版本的时候，我们已经体验过这个情况。RTnet显示了良好的性能，抖动很小。我们再一次观察到RTAI和Xenomai有细微的差别，可能是中断执行路径不同引起的。在上述测试中，我们禁止了RTnet的所有以太网访问控制规则。我们使能以太网时分多址(TDMA)访问规则后重复RTnet的上述实验。该规则由RTnet选择性提供，旨在强制网络访问中的决定论，避免可能的冲突。使用循环时间100s，数据分组时间片40s 的TDMA，我们获得了一个约150s整体的延迟和约50s的抖动。减少TDMA的周期时间是不可能的（因此减少延迟和抖动也是不可能的）因为这将导致不可接受的CPU负荷。5. 讨论本篇文章的目的是为了评估Linux实时解决方案替代RFX-mod目前正在使用的VxWorks的可能性。基于性能测定的结果，我们可以得到以下结论：l 当前Linux 2.6内核的性能非常好，在小的专用系统是可以接受的。但RFX-mod的反馈控制系统并非如此，涉及的控制单元要处理高数据吞吐量的输入/输出和网络通信。l RTAI和Xenomai都值得考虑。Xenomai的性能表现略次于RTAI，主要是因为它分层的方法在中断管理中引入一些开销。另一方面，Xenomai结构化更优，很多平台可以使用。此外，Xenomai提供一组模拟层，这在大型系统的移植中会非常有用。l RTAI和Xenomai在软件开发时用户友好都不及VxWorks。因为实时任务要在内核模式执行以实现最佳性能，程序员不能使用通常在用户空间可用的系统服务，调试变得非常困难。然而，对于Xenomai和RTAI，让用户进程成为实时却是可能的。允许实时应用用户进程的开发简化了实时系统程序开发也允许IPC Linux标准进程。实时用户进程靠一个与Linux调度器协同工作的专门的调度程序进行管理，当用户进程需要实时性时，窃取它们。与内核进程不同，为用户进程进行上下文转换需要重新映射页表，这是一个潜在的耗时的操作。因为这个原因我们计划进一步测试量化MMU重新映射对上下文切换的影响。l 网络性能是对RTAI和Xenomai最有利的支持。UDP已成功用于实时网络通信。RTnet被证实是一种良好的解决方案，尤其是的与目标板的最新版VxWorks IP堆栈的不良性能给我们的用户体验相比的时候。RTnet只在不使能TDMA时可以达到最佳性能，这似乎最适合有大量接入点但是没有严格时间要求的系统（访问冲突的机率更高）。RFX-mod并不是运行在这样的环境下，只有不到10个控制单元。因此我们可以说，RTAI和Xenomai都可以在RFX-mod，或者更广泛的说，在聚变装置的实时控制系统有效替代VxWorks。参考文献1 A. Luchetta and G. Manduchi, “RFX数字反馈控制的总体构架，实现和性能” IEEE Trans. Nucl. Sci., vol. 47, pp. 186191, 2000.2 M. Cavinato, G. Manduchi, A. Luchetta, and C. Taliercio, “核聚变实验中一般目的的实时控制框架” Trans. Nucl. Sci., vol. 53, pp. 10021008, 2006.3 Wind River 主页, 在线.可访问: http: .4 J. A. Stillerman, M. Ferrara, T. W. Fredian, and S. M. Wolfe, “Alcator C-Mod 数字实时等离子体控制系统” Fus. Eng. Des., vol. 81, pp. 19051910, 2006.5 B. G. Penaflor, J. R. Ferron, M. L. Walker, D. A. Piglowski, and R. D. Johnson