问题描述
目前 clock_nanosleep
在 Debian Jessie 上使用 CLOCK_MONOTONIC_RAW 返回 EOPNOTSUPP.
Currently clock_nanosleep
with CLOCK_MONOTONIC_RAW on Debian Jessie returns EOPNOTSUPP.
如何解决此问题并补偿可能应用于计时器循环中的 CLOCK_MONOTONIC 的可能的 NTP 调整?
How to work around the issue and compensate for possible NTP adjustments which might get applied to CLOCK_MONOTONIC in the timer loop?
clock_nanosleep
本身是否也受 NTP 调整的影响?如果在睡眠时进行调整,clock_nanosleep
会比预期的睡眠时间更长吗?
Is clock_nanosleep
itself also affected by NTP adjustments? If adjustments happen while sleeping, will clock_nanosleep
sleep longer that expected?
在我的特定情况下,我是否应该担心 CLOCK_MONOTONIC NTP 可能的调整?考虑到我的代码将在没有实时时钟的系统上运行并且可能不时失去 Internet 连接,NTP 对 CLOCK_MONOTONIC 应用的最大可能时间跳跃"是多少?
And should I be worried at all about possible CLOCK_MONOTONIC NTP adjustments in my specific case? What would be the largest possible "time jump" applied by NTP to CLOCK_MONOTONIC, considering that my code will be running on a system without real-time clock and it might lose Internet connection from time to time?
说来话长.我正在使用一个简单的循环来模拟音频文件播放,我需要保持一致的播放位置.
The long story. I'm using a simple loop to emulate audio file playback and I need to maintain consistent playback position.
clock_nanosleep
带有 TIMER_ABSTIME 标志似乎做得很好,但我不确定 CLOCK_MONOTONIC 是否足以避免播放位置出现明显的跳跃.
clock_nanosleep
with TIMER_ABSTIME flag seems to be doing the job fine, but I'm not sure if CLOCK_MONOTONIC is enough to avoid noticeable jumps in playback position.
这是我正在使用的代码:
Here is the code I'm using:
clock_gettime(CLOCK_MONOTONIC, &deadline);
// run until asked to stop
while(!need_quit(stop_mutex_signal)) {
// do stuff ...
// add time ms to previous deadline
deadline.tv_nsec += device->periodTime * NANOSECONDS_PER_MILLISEC;
// normalize the time to account for the second boundary
if(deadline.tv_nsec >= NANOSECONDS_PER_SEC) {
deadline.tv_nsec -= NANOSECONDS_PER_SEC;
deadline.tv_sec++;
}
if(clock_nanosleep(CLOCK_MONOTONIC, TIMER_ABSTIME, &deadline, NULL) != 0)
{
// something happened - error or exit signal, cannot continue
return;
}
}
我很好奇,为什么还没有实现 clock_nanosleep
中对 CLOCK_MONOTONIC_RAW 的支持?这是否意味着 CLOCK_MONOTONIC 对于大多数情况就足够了,即使是音频/视频同步?
I'm curious, why support for CLOCK_MONOTONIC_RAW in clock_nanosleep
is not yet implemented? Does it mean that CLOCK_MONOTONIC is enough for most cases, even for audio/video synchronization?
推荐答案
CLOCK_MONOTONIC
是单调的.它不受来自 ntp 或其他方式的任何跳转的影响.它唯一受制于漂移率调整,这通常由 ntpd 通过 adjtime
或类似方式完成.在很短的时间间隔内,这种调整根本不可见.无论如何,只要您的系统没有被恶意配置,它比CLOCK_MONOTONIC_RAW
更准确.作为一个例子(编造的数字,但它们可能在合理范围内)CLOCK_MONOTONIC_RAW
可能以 999950000 纳秒/实际秒的速率运行,并且 CLOCK_MONOTONIC
可能以一个速率运行实际每秒 1000001000 纳秒.
CLOCK_MONOTONIC
is monotonic. It is not subject to any jumps, from ntp or otherwise. The only thing it is subject to is drift rate adjustment which is usually done by ntpd via adjtime
or similar. For short intervals this adjustment is not going to be visible at all. In any case, as long as your system is not maliciously configured, it's much more accurate than CLOCK_MONOTONIC_RAW
. As an example (made up numbers but they're probably in the realm of reasonableness) CLOCK_MONOTONIC_RAW
might be running at a rate of 999950000 nanoseconds per actual second and CLOCK_MONOTONIC
at a rate of 1000001000 nanoseconds per actual second.
这篇关于Clock_nanosleep() 尚不支持 CLOCK_MONOTONIC_RAW.如何处理?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持!