InfiniBand：传输速率取决于MPI_Test*频率

Question

我正在编写一个多线程的OpenMPI应用程序，使用来自几个线程的MPI_Isend和MPI_Irecv在InfiniBand RDMA上的排名之间每秒交换数百条消息。

传输大小为400-800K字节，为每个排名生成约9 Gbps的流出和流入数据，远远低于FDR的容量。简单的MPI基准测试也显示出良好的性能。

使用MPI_Testsome在专用线程中轮询所有活动传输，以检查传输是否完成。

我所实现的传输速率取决于消息速率，但更重要的是MPI_Testsome的轮询频率。也就是说，如果我以10毫秒的频率轮询，请求完成的时间比我每1毫秒轮询要晚。

我希望，即使我以10毫秒的频率轮询而不是每1毫秒轮询，我也最多只能在9毫秒内被通知传输已完成。我不希望传输本身通过减少MPI_Testsome的调用延迟完成，并因此降低总体传输速率。我期望MPI_Testsome完全是被动的。

有人知道为什么会出现这种行为吗？

- Jan David Mol

Answer 1

观察到的行为是由于在Open MPI中实现操作进展的方式所致。无论是同步还是异步地发布发送或接收操作，都会导致一系列内部操作被排队。进展基本上是处理那些排队操作。您可以在库构建时选择两种模式：异步进展线程模式和默认模式（不带异步进展）。

当使用启用异步进展线程的库进行编译时，后台线程负责处理队列。这允许在用户代码并行执行背景传输，但会增加延迟。如果没有异步进展，则操作速度更快，但只能在用户代码调用MPI库时才能进行进展，例如在MPI_Wait或MPI_Test及其相关函数中。 MPI_Test函数族的函数实现方式使其尽可能快地返回。这意味着库必须在调用中平衡一个权衡，从而降低其速度，或者快速返回，这意味着每次调用时可以进展较少的操作。

Open MPI的一些开发人员，特别是Jeff Squyres，偶尔访问Stack Overflow。他可能可以提供更多详细信息。

这种行为几乎适用于所有MPI实现，除非有强助硬件支持。

- Hristo Iliev

---

谢谢！我没有意识到异步进展不是默认的。根据gdb，我有一个“btl_openib_async_event_thread”正在运行。也设置了“btl_openib_use_async_event_thread”选项。我将从重新构建OpenMPI开始，看看是否可以更精细地控制该方面。 - Jan David Mol

那个 openib 异步线程不是我提到的异步进度线程。它从InfiniBand完成队列中读取通知消息，可能会更新挂起事件在进度队列中的状态。 - Hristo Iliev