测量 Windows 上的跨进程延迟

Question

我正在将延迟测量构建到我正在构建的通信中间件中。我让它工作的方式是我定期从我的发布应用程序发送探测消息。订阅应用程序接收此探测，将其缓存，并在自己选择的时间发回回显，并记录消息被“搁置”的时间。订阅应用程序接收这些回显，并将延迟计算为 (now() – time_sent – time_on_hold) / 2。

这有点有效，但当“保持时间”大于 0 时，数字有很大不同 (3x)。即，如果我回显消息立即返回，我在我的开发环境上得到了大约 50us，如果我等待，然后将消息发回，时间会跳到 150us（尽管我会打折我等待的任何时间）。我使用 QueryPerfomanceCounter 进行所有测量。

这一切都在一个 Windows 7 盒子里。我在这里缺少什么？

TIA。

Answer 1

更多信息。我使用以下方法来测量时间：

   static long long timeFreq;

   static struct Init
   {
      Init()
      {
         QueryPerformanceFrequency((LARGE_INTEGER*) &timeFreq);
      }
   } init;

   long long OS::now()
   {
      long long result;
      QueryPerformanceCounter((LARGE_INTEGER*)&result);
      return result;
   }

   double OS::secondsDiff(long long ts1, long long ts2)
   {
      return (double) (ts1-ts2)/timeFreq;
   }

在发布端我做了类似的事情：

Probe p;
p.sentTimeStamp = OS::now();
send(p);
Response r = recv();
latency=OS::secondsDiff(OS::now()- r.sentTimeStamp) - r.secondsOnHoldOnReceiver;

在接收端：

Probe p = recv();
long long received = OS::now();
sleep();
Response r;
r.sentTimeStamp = p.timeStamp;
r.secondOnHoldOnReceiver = OS::secondsDiff(OS::now(), received);
send(r);

Answer 2

好的，我编辑了我的答案以反映您的答案：很抱歉延迟了，但我没有注意到您通过创建答案来详细说明了该问题。

从功能上看，您似乎没有做错什么。

我认为，当您在本地主机条件之外分发应用程序时，与正常运行的网络的平均延迟相比，额外的 100us（如果它确实大致恒定）将显得微不足道。

为了回答您的问题，我认为服务器端存在需要调查的线程/中断调度问题，因为您似乎没有在客户端上执行任何未考虑到的操作。

尝试以下测试场景：

• 向客户端 A 和 B 发送两个探测。（均为本地主机）
• 在将探测发送到客户端 A 后一秒（或 X/2 秒）将探测发送到“客户
• 端 B”。确保“客户端 A” ' 等待两秒（或 X 秒），'客户端 B' 等待'一秒（或 X/2 秒）。

这个想法是希望两个客户端都能在大致相同的时间发回他们的探测答案，并且都在睡眠后/wait（执行暴露问题的操作）。目标是尝试获取其中一个客户的响应，以“唤醒”发布商，看看是否会立即处理下一个客户的响应。

如果这些返回的探测器之一没有显示异常（很可能是第二个响应），则可能表明发布者线程正在从睡眠周期中唤醒（在recv第一个响应上）并立即可用于处理第二个响应。

同样，如果事实证明 100us 延迟大致恒定，则它将是 1ms 的 +-10%，这是适合实际网络条件的时间范围。