UDP端口的低延迟读取

Question

我正在从UDP端口读取单个数据项。最重要的是，这个读取是尽可能低的延迟。目前，我正在通过boost::asio库的async_receive_from方法进行阅读。有人知道在数据包到达网卡和在用户代码中调用回调方法之间会经历什么样的延迟吗？

Boost是一个非常好的库，但非常通用，有没有更低延迟的替代方案？

欢迎所有关于编写低延迟UDP网络程序的意见。

编辑:另一个问题是，有没有一种相对可行的方法来估计NIC和用户模式之间的延迟？

Answer 1

您的延迟将有所不同，但它将远远不是您能获得的最好的延迟。这里有几个东西会阻碍你实现更好的延迟：

Boost.ASIO

为了调用与读取操作相关的回调函数，

1. 它会不断地分配/释放内存来存储“状态”。
2. 它会进行不必要的mutex锁定/解锁为了支持异步和同步approaches.
3. The的不完整组合。最糟糕的是，它会不断地在底层通知机制中添加和删除事件描述符。

总而言之，对于高级应用程序开发人员来说，asio是一个很好的库，但它有很高的价格标签和大量消耗CPU周期的小精灵。另一种选择是libevent，它要好得多，但仍然旨在支持许多通知机制，并且是独立于平台的。没有什么能比本机机制更好，比如epoll。

Other things

1. UDP堆栈。对于延迟敏感的应用程序来说，它做得并不是很好。最流行的解决方案之一是OpenOnload。它绕过堆栈，直接与NIC.
2. Scheduler.一起工作默认情况下，计划程序针对吞吐量而不是延迟进行优化。你将不得不调整和调整你的操作系统，以使其面向延迟。例如，Linux有很多"rt“补丁让purpose.
3. Watch不能休眠。一旦你的进程处于休眠状态，你就永远不会有一个好的唤醒延迟，而不是不断地消耗CPU并等待一个数据包与其他IRQ，进程等arrive.
4. Interference。

我不能告诉你确切的数字，但是假设你使用Boost和一个普通的Linux内核，使用一个普通的硬件，你的延迟将在大约50微秒到大约100毫秒之间。随着你获得更多的数据，它会有所改善，在某个点之后开始下降，并将始终在范围内。我想说的是，如果你对这些数字没意见，那就别费心优化了。

Answer 2

我认为在“旋转”循环线程中使用recv()并将线程连接到单个CPU核心(处理器亲和性)，延迟应该比使用select()低，在我的测试中，select()的精度在1到10微秒之间变化，而在我的测试中自旋循环的精度为1微秒。