如何分析 NetPIPE 基准测试的结果

Question

我使用基准工具NetPIPE 测量了两台 Raspberry Pi Model B 单板计算机之间的以太网延迟和吞吐量。该基准测试了两个进程之间的一系列消息大小。仅使用 TCP 作为端到端协议执行一次，使用 Open MPI 消息传递层库执行一次。

连接不是直接链接。非托管第 2 层交换机（10/100 Mbps 以太网）位于两个设备之间。

MTU=1500 字节。

这些数字表明，使用 MPI（也使用 TCP 作为传输层协议）是一种开销，会对吞吐量和延迟产生负面影响。使用 MPI 时测得的最佳吞吐量是 65 Mbit/s。仅使用 TCP 时，吞吐量高达 85 Mbit/s。

只要有效负载适合单个 TCP 段，使用 MPI 时的延迟大约比仅使用 TCP 时差十倍。最大传输单元 (MTU) 指定以太网帧内的最大有效负载，在我们的集群中为 1500 字节。因此，指定 TCP 段内最大有效负载的最大段大小 (MSS) 为 1460 字节。

一些问题：

• 为什么 MPI 图与 TCP 图有更多异常值？这在左下图中可以清楚地看到。这是因为操作系统的进程调度吗？ TCP 堆栈是 linux 内核的一部分，因此在内核空间中执行。 MPI 库在用户空间中执行。

• 为什么与 TCP 相比，使用 MPI 时的延迟时间常数更长？在右上图中可以清楚地看到。

• 我错过的结果有什么进一步的解释吗？

顺便说一句：整体以太网性能不佳可能是因为 Raspberry Pi 的 10/100 Mbit 以太网控制器在内部连接到 USB 2.0 集线器。

更新

性能下降，尤其是 4 MB 左右的有效负载大小可能是由于 Raspberry Pi 节点的 CPU 资源有限造成的。我用 htop 检查了 CPU 利用率，在运行 MPI 基准测试时它几乎完全被利用了。

Answer 1

大约 512 KiB 的性能下降是由于 MPI 协议：

• 渴望模式 => 1x 往返时间
• rendevouz => 2 倍往返时间

见：https://computing.llnl.gov/tutorials/mpi_performance/#EagerVsRendezvous 更改配置的默认点取决于所选的 MPI 实现。还有配置变量可以更改它，并且，在您的情况下，您应该稍后从渴望切换到 rendevouz。 额外的延迟会导致性能再次缓慢提高，直到传输大小达到 1 MiB。我不清楚后来的性能下降。