python - 在 windows 10 中以高分辨率测量两个 python 进程之间的 zmq 延迟

Question

我想以高分辨率(以 us/ns 为单位)(windows 10) 测量两个 python 进程之间的 zeromq 延迟。

这是我的代码。

子.py

import sys
import zmq
import time

port = "5556"
if len(sys.argv) > 1:
    port =  sys.argv[1]
    int(port)

if len(sys.argv) > 2:
    port1 =  sys.argv[2]
    int(port1)

# Socket to talk to server
context = zmq.Context()
socket = context.socket(zmq.SUB)

print('connecting to publisher')
socket.connect ("tcp://localhost:%s" % port)

if len(sys.argv) > 2:
    socket.connect ("tcp://localhost:%s" % port1)
topicfilter = "10001"
socket.setsockopt_string(zmq.SUBSCRIBE, topicfilter)

total_value = 0
while True:
    string = socket.recv()
    got_time = time.time() # resolution in windows 10: 15.6ms
    topic, msgdata = string.split()
    dur = got_time - float(msgdata)
    print('it took %.5fms from pub' % (dur*1000))

pub.py

import zmq
import random
import sys
import time

port = "5556"
if len(sys.argv) > 1:
    port =  sys.argv[1]
    int(port)

context = zmq.Context()
socket = context.socket(zmq.PUB)
socket.bind("tcp://*:%s" % port)

topic = 10001
while True:
    msgdata = time.time() # resolution in windows 10: 15.6ms
    socket.send_string("%d %.5f" % (topic, msgdata))
    print("topic:%d, msg:%.5f" % (topic, msgdata))
    time.sleep(1)

但是，由于 time.time() 函数在 Windows 10 中的分辨率仅为 15.6 毫秒(Windows 默认定时器周期)，我无法使用代码测量低于 15.6 毫秒的延迟。

所以我想到了使用 time.perf_counter() 函数，它具有微秒级的分辨率，但它在测量两个进程的时间差时也没有用，因为 time.perf_counter() 函数的引用点未根据 doc 定义.

有没有其他方法可以高分辨率(微秒或纳秒单位)测量两个python进程之间的时间差？

Answer 1

是的，有:ZeroMQ 有一个用于执行此操作的内置工具，它独立于平台并且使用起来确实很不错。

aClk = zmq.Stopwatch()                         // creates a Stopwatch instance
...
..
.
aClk.start();_=aProcessUnderTEST();aClk.stop() // measure an embedded latency
2169L                                          // <-------------------latency[us]

.stop() 方法返回一个长数字 ( 1234L )，表示 分辨率为 [us] 的持续时间。

提示:在深入测试性能细节时避免任何打印和内存分配操作(总是预分配，总是宁愿分配一个函数的返回值，而不是获取解释器的结果值 repr/打印开销包含在测量嵌入的代码部分 == 通过分配给 _ 避免 repr() 开销(没有任何分配开销的特殊符号(变量))。

---

仍然有一些问题需要解决(或注意):

- 在分布式主机上，(非本地进程开始/结束)您需要找到并同步一个公共(public)引用时钟来计算有意义的差异，否则必须重新安排测试在消息/信号传递中形成循环，并返回以在同一 refClk 端进行测量。对于高分辨率时钟(具有低于 1E-6 的分辨率)、单调性(不受 NTP 调整影响)的其他方面，请检查 time.process_time()、time.perf_counters() 并且可以使用更复杂的场景来进行差异化测量，因为一条消息触发测试测量的开始，而第二次到达触发测试测量结束，携带发起方消息间持续时间(处理、预期延迟等)开销(在 [us] 中)作为有效载荷(从接收方的结果中替换)边 )。无论如何，在处理子[us]-事件时要小心下面提到的系统不确定性。

- 期待 O/S 干预各种 ZeroMQ 传输类。例如，tcp:// 传输类是 Windows 缓冲的主题，并且已经发布了在 Windows TCP/IP 堆栈上非常不可预测的延迟有线传输(谷歌他们，反制措施存在，谷歌他们也是)。

- 预计 O/S 调度程序会影响 aProcessUnderTEST 在所有其他系统 + 用户处理和优先资源处理中的执行方式。