python - Linux 中的精确时间测量

Question

我正在从不同来源收集数据，并希望尽可能准确地获取时间。此外timeit，time. monotonic, time.time, 有没有类似 Linux 的“实时”方法？

（我知道，这取决于操作系统（open suse），多任务/多用户系统几乎不会像实时系统那样准确，但在某种程度上，我想在普通 Linux 系统上尽可能准确地测量时间。 )

使用 time.time 方法的示例。如果我在循环中使用此方法，我安装睡眠 4 秒（从第 8 秒开始），测量结果为：

absolute                distance to next measurement
8.040261268615723       0.01363372802734375     
12.053894996643066      0.012626409530639648    
16.066521406173706      0.020114421844482422    
20.08663582801819           

我有一个特定的开始时间和循环的执行时间，大约为 20 毫秒，因为从一个测量值到下一个测量值的距离约为 0.02 秒。

附录：time.monotonic 的时间测量与上面的（time.time）几乎相同。

循环的代码片段：

seconds = 4
MAX = 11

     for i in range (1,MAX+1):
        sleep (seconds)                                    # 
        mt1.tick()                                          # take time stamp
        Ergebnis.append(mt1.elapsed_time)                   # get absolute time
        Differenz.append(mt1.elapsed_time - i*Sekunden)     # get elapsed time difference (compared to ideal time)

标签： pythonlinuxtime

Answer 1

我进行了一些测量并搜索了有关时间问题的答案，并得出了某种（对我而言）重要的结论。许多高票数的答案提到选择适当的计时函数将提供最佳响应时间，例如 time.monotonic (oder monotonic_ns) 或 timeit.default_timer() （因为在那里，python 解释器会选择最充分和准确的测量) 或 time.time()。首先，我将展示测试情况以进行澄清。但这并不像基本问题那样重要，即哪种计时方法会产生最准确的时间。我只是为了更好地理解而展示它，因为它有一个问题。

我用三种计时方法进行了测试，time.monotonic()、timeit.default_timer() 和 time.time()。虽然 timeit.default_timer() 似乎是最准确的计时器，但与其他计时器的差异对我来说并不那么令人印象深刻。然后我想到了多用户/多处理和进程的优先级以及多用户系统中的调度。open suse 中的调度程序就像任何其他多用户系统一样分配进程时间，并且调度取决于进程的优先级。我查看了我的默认进程优先级，默认为 19。我将优先级更改为参数并再次进行测试，响应时间确实取决于进程优先级，似乎有一个硬石灰，它是在我的系统“0”上：似乎所有关于进程优先级“0”的进程都安排在慢车道上。相反，所有优先级低于（高于）0 的进程都在加快处理器时间。在上面的循环中，我避免了会减慢进程的系统调用，我收集了数据来计算循环后面的结果。数据显示绝对延迟 1) 取决于进程优先级和 2) 不同方法的绝对延迟仅在进程优先级高于 0 时显着不同。在 0 下似乎无论我选择哪种方法。处理一个循环的绝对延迟比进程优先级 0 高 20 毫秒以上，比该优先级低大约 4 毫秒。斜率的上升是由于循环的重复处理和每一遍的求和。在上面的循环中，我避免了会减慢进程的系统调用，我收集了数据来计算循环后面的结果。数据显示绝对延迟 1) 取决于进程优先级和 2) 不同方法的绝对延迟仅在进程优先级高于 0 时显着不同。在 0 下似乎无论我选择哪种方法。处理一个循环的绝对延迟比进程优先级 0 高 20 毫秒以上，比该优先级低大约 4 毫秒。斜率的上升是由于循环的重复处理和每一遍的求和。在上面的循环中，我避免了会减慢进程的系统调用，我收集了数据来计算循环后面的结果。数据显示绝对延迟 1) 取决于进程优先级和 2) 不同方法的绝对延迟仅在进程优先级高于 0 时显着不同。在 0 下似乎无论我选择哪种方法。处理一个循环的绝对延迟比进程优先级 0 高 20 毫秒以上，比该优先级低大约 4 毫秒。斜率的上升是由于循环的重复处理和每一遍的求和。数据显示绝对延迟 1) 取决于进程优先级和 2) 不同方法的绝对延迟仅在进程优先级高于 0 时显着不同。在 0 下似乎无论我选择哪种方法。处理一个循环的绝对延迟比进程优先级 0 高 20 毫秒以上，比该优先级低大约 4 毫秒。斜率的上升是由于循环的重复处理和每一遍的求和。数据显示绝对延迟 1) 取决于进程优先级和 2) 不同方法的绝对延迟仅在进程优先级高于 0 时显着不同。在 0 下似乎无论我选择哪种方法。处理一个循环的绝对延迟比进程优先级 0 高 20 毫秒以上，比该优先级低大约 4 毫秒。斜率的上升是由于循环的重复处理和每一遍的求和。

有了这个结果，我可以粗略地估计我的测量时间，在我的情况下，当测量时间超过几秒（在我的情况下约为 30 秒）时，大约 4 毫秒的精度就足够了。不仅如此，因为似乎进程优先级 0 下的响应时间是可预测的（而不是像 0 以上那样随机），我可以计算我的测量中的延迟，因为响应时间似乎与指令数量呈线性（并且相关）。