如何编写一个尽可能接近实时特性的应用程序？答案

【问题标题】：How to write an application to have as close to real -time characteristics as possible?如何编写一个尽可能接近实时特性的应用程序？
【发布时间】：2011-01-09 05:54:07
【问题描述】：

我正在寻找设计需要尽可能接近实时响应的应用程序的最佳方法。我考虑过使用精简内核并将软件直接构建到其中，但我认为这不是最好的解决方案。

我对在硬件中创建一些东西很感兴趣（我一直在 SO 上阅读有关此内容的内容）并想知道是否有人构建了类似的东西，如果有，他们使用了什么硬件？

例如，是否有具有可编程千兆以太网的设备？即卡上的CPU？然后我可以编写一个内核驱动程序来通信/控制卡上运行的应用程序 - 由于它靠近网络接口，因此基于网络流量做出决策的延迟会更低......

有人做过吗？如果是这样，任何人都可以推荐我应该研究的任何硬件/软件吗？

【问题讨论】：

这取决于操作系统，如果你有一个非实时操作系统，你可以做的不多......
您能否详细说明您的要求？你说的好像你需要一个实时硬件解决方案，但希望它作为台式机/服务器/笔记本电脑上的外围设备运行。对吗？
我目前在用户级 C 应用程序中处理数据。然而，由于应用程序经常被内核抢占，因此很难获得我们需要的响应时间。我之所以考虑双硬件/软件解决方案，是为了让硬件能够专注于任务而不会中断。通过为它编写一个驱动程序，可以读取用户空间中的统计信息和信息，这也将允许控制和微调卡上运行的应用程序。我猜想像如何使用 GPU 来卸载图形处理以释放 CPU。
@Pete：我会努力让操作系统/调度程序首先完成他们的工作......肯定会降低影响。您是否按实时优先级安排任务？任务执行时间是多少？您在寻找什么延迟范围？您的计算线程是否因任何原因阻塞（互斥体？）？
@andersoj 我已经尝试运行具有实时优先级的线程，但是虽然这改善了响应时间，但它们仍然不理想，响应时间本身波动很大（+/- 20ms）。因此，我正在寻找蓝天解决方案。假设我想要一个 0.5 毫秒的保证响应时间（我确实会在美好的一天看到），那么构建它的最佳方法是什么？

标签： time hardware real-time

【解决方案1】：

一般 cmets

您可能需要更具体地说明您的要求，然后人们才能回答。我们中的许多人都构建了实时系统，但请记住 a) 实时与真正快速不同，b) “实时”是一系列不同及时性标准的总称。

您需要哪些活动来确保及时性？您在问题中提出的解决方案有点异国情调，只有在您陈述您的要求并且您确定更传统的方法不够用时才应考虑。

构建实时应用程序/系统与设计其他任何东西没有什么不同。但是，您确实需要以与通常捕获“功能”需求（例如，功能/方法的前置、后置和不变条件）相同的精度来捕获每个活动的及时性需求。当您开始了解所有这些需求的总和时，困难的部分就出现了——这与系统设计的其他方面不太一样。

即使您无法将其应用到所有严格的细节中，我也建议您尝试根据RMA analysis 来构建应用程序的活动。许多动态应用程序不会完全屈服于分析，因为您没有足够的数据（它们本质上是不确定/动态/非确定性的），但尝试应用该规则会有所帮助。

无论如何，从分析开始，而不是从一些性感（和复杂）的解决方案开始......

一些你应该捕捉的东西：

您希望系统执行哪些自然任务/活动（在问题空间中）？这是开始设计的好地方，但您的实现可能需要转变。
您需要管理哪些资源？（CPU？网络？内存？）
您能否确保资源保持负载不足？如果没有，您需要进行一些可行性分析和admission control policy 或“减载”。请注意，这捕获了“重要性”或“优先级”的一个维度，并且最好与另一个维度解耦......
时间限制是什么？这是“紧迫性”维度。这可能是延迟要求，或其他。这些约束是硬的还是软的？聚合还是按任务？（有关区分紧迫性和重要性的调度方法的有趣和深入了解，请参阅 CMU 的 RKC's thesis（或 shorter summary），但在继续之前请深呼吸......）
您将如何表示实施中每个活动的时间约束上下文？请注意，在大多数常见操作系统中，CPU 没有“最后期限调度程序”，通常的方法是将紧急情况映射到优先级（参见 RMA），但这仅在资源负载不足时才有效。
您希望如何处理多资源挑战？这里几乎没有严格的分析工具可以提供帮助，通常目标是尽可能多地过度配置并在系统边界应用准入控制。如果这是一个系统，您要求包括网络传输和处理在内的活动具有及时性，那么您可能会考虑以 QoS 流量管理的形式应用准入控制，从而减少（而不是消除）对 CPU 负载的担忧。
您的吞吐量要求是什么？
您的活动到达模式是什么？例如，您能确保最短的到达间隔时间吗？
您的系统/应用程序正确运行需要多大的信心？

基于其他 cmets 的编辑

在转向混合硬件/软件方法之前，请确保先用尽软件解决方案。如果您的任务被内核抢占了，那么您应该努力控制它。

什么是操作系统？如果是 Linux、最近的 Windows 或 Mac OS X，您应该能够以实时优先级调度您的处理线程，并最大限度地减少内核引起的抢占。如果您真的要消耗 CPU，也许您应该考虑使用双 CPU 方法，在这种方法中，您可以隔离单个 CPU 来处理应用程序（同样，取决于操作系统）。

啊哈，0.5ms 的响应时间开始有点澄清情况了。如果您使用的是通用操作系统，那么一致的亚毫秒延迟可能会有点挑战。

什么处理器（和时钟速度？）

听起来您有一些工作（或接近）代码。您已经进行了一些分析，因为您认为抢占式正在杀死您。您采取了哪些措施来消除抢占？您引用的“决策”活动是一个非常小/简单的评估吗？它是确定性的吗？ 0.5ms 是物理界限，还是由于包含系统其他部分的延迟预算而征收的？

【讨论】：

我之所以说实时而不是低延迟，是因为我需要 0.5 毫秒范围内的响应。之后的任何事情都没有用。我试图用一个用户级应用程序来创建它，但它发生了太多事情，以至于它无法可靠地做出这种响应。应用程序接收数据馈送，做出决定，然后发送适当的响应。我的目标是让决策/响应更靠近设备，以便操作系统和用户级应用程序对决策/响应周期的影响有限。
这是一次性应用程序，还是您需要构建以扩展的东西？我想我的下一步是按照您的建议将（仅绝对必要的）东西迁移到内核驱动程序中，并且只有在分析完之后，才考虑转向花哨的硬件解决方案。
扩展对于这个应用程序来说不是一个大问题，我同意硬件解决方案是从破解内核的一大飞跃（这本身并不适合胆小的人）。我将考虑再次将其写入内核。我开始寻找替代方案的原因是因为我读到将内容放在内核中而不是用户空间并没有太多好处，而且它可能会导致严重的问题并且难以调试 - 尽管大概不比硬件设备更难...... . 目前我使用的是 Linux 2.6
@Pete，我同意一般意义上的你可以在用户空间中做得很好，并且出于各种原因将东西移入内核是不好的。这是 TCP/UDP 吗？原始以太网？
数据馈送是 TCP，但应用程序在受限环境中工作，因为我不需要在设备本身上实现完整的 TCP 堆栈。硬件解决方案的建议是否可行？诚然，这需要大量的工作（虽然学习经验很好），但我没有任何实际操作经验，即我什至会在哪里寻找这样的设备。我猜基本上是一个可编程的千兆以太网卡。