线程测试之间的延迟：Linux 裸机与 VM 上的 QNX答案

【问题标题】：Latency between thread test: Linux bare metal machine vs QNX on a VM线程测试之间的延迟：Linux 裸机与 VM 上的 QNX
【发布时间】：2020-07-27 13:04:03
【问题描述】：

我最近对这两种设置进行了延迟比较： a) Ubuntu 16.04 在 12 核主机上运行； b) 在笔记本电脑主机上运行 VMware 的来宾 QNX（分配给 QNX VM 的 4 个内核）——我目前没有更好的 QNX 设置。

测试场景：运行 10 个线程，每个线程每 30 毫秒向随机选择的接收线程发送一条消息 - 消息率确实非常低；消息机制是使用条件变量实现的，每个线程都有自己专用的 rx prod-consumer 队列和自己的条件变量和互斥锁 - 因此队列之间没有干扰。我测量消息被构造/发送和接收线程获取消息之间的时间。每个线程的均值和 std_dev min max 都被捕获。

结果令人惊讶地有利于 QNX（尽管它在 VM 上运行）。 10us 与 40us。

对于 Linux 上的线程（秒）：mean=0.000038076 std_dev=2.7523e-05 min=0.000000254 max=0.000177410 sampleSize=1023 对于线程 QNX（秒）：mean=0.000011351 std_dev=0.000105937 min=0.000000000 max=0.000999987 sampleSize=969

我注意到 QNX 端的时钟不如 Linux 端那么精确（分辨率方面），因为我确实看到可测量的最小延迟为 0。

我只是想知道它是否符合其他人的经验-Linux线程条件唤醒平均需要40us吗？顺便说一句，如果 QNX 时间精度是 100us 而 Linux 是纳秒，这个差异会影响统计数据吗？谢谢。

【问题讨论】：

您还测量了线程之间传递的时间，而不仅仅是唤醒时间。此外，如果线程实际上是睡着的，它被告知醒来并不能保证它甚至会在本世纪发生。那是操作系统线程管理。此外，如果 QNX 的耗时小于其精度，则该值可能毫无意义。
QNX什么味道？
您正在两个非常不同的硬件平台上进行测试。我认为您无法通过比较收集的统计数据得出很多有意义的结论。
克里斯，谢谢你的评论。测试场景是，每个线程都会被它的 prod-consume 条件变量阻塞，直到有消息进入它，然后它唤醒（解除阻塞）并读取消息。我测量了可以在这里测量的内容，这是许多应用程序的现实场景。所以我不确定你的意思。
@user4581301，这是用于 x86 (VMWARE) 的 QNX VM，名称为 QNX-SDP-x86_64，版本为 7.0.0

标签： c++ linux pthreads qnx

【解决方案1】：

事实证明，延迟测试对硬件的敏感度（以不同的方式）比我之前想象的要高。较新的 12 核 CPU 主机启用了超线程，并产生 40us 延迟数。我搬到了一个旧的 4 CPU 并禁用了超线程的机器，延迟数下降到 15-16us。这与 QNX VM 编号在同一范围内。我希望我可以让平台在测试中更加一致，以便在未来获得更确凿的答案。

新的 Linux 结果：mean=0.000015819 std_dev=1.39205e-05 min=0.000000503 max=0.000117652 sampleSize=1528

【讨论】：

VMware 使用各种系统时间源将管理程序开销分摊回虚拟机，并在 cpu 之间对齐时钟源。作为一种粗略的测试，试着让你的微基准测试连续运行 10 或 20 秒，然后使用外部的东西来交叉验证时间。您可能只能获得 1/10 秒的分辨率，但它应该显示是否存在重大偏差。如果我没记错的话，菜单/.vmx 中有一个“高级”切换来调整或禁用这种摊销。