☰

问题

tag-icon • tag-icon ntp jitter
问题

问题

如何修复瞬态高 NTP 抖动？

背景信息

我的私有网络上有一个 NTP 服务器。我的服务器与此时钟同步，通常一切正常。输出示例集：

ntpq> pe
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
*10.10.10.249    10.10.100.20     3 u  367 1024  377    0.096    0.145   0.142
ntpq> as

ind assid status  conf reach auth condition  last_event cnt
===========================================================
  1  2378  962a   yes   yes  none  sys.peer    sys_peer  2
ntpq> rv 2378
associd=2378 status=962a conf, reach, sel_sys.peer, 2 events, sys_peer,
srcadr=10.10.10.249, srcport=123, dstadr=10.10.200.1, dstport=123,
leap=00, stratum=3, precision=-18, rootdelay=1.190, rootdisp=37.155,
refid=10.10.100.20,
reftime=df134714.c026b762  Mon, Aug  6 2018 22:15:48.750,
rec=df134a04.507b5ad6  Mon, Aug  6 2018 22:28:20.314, reach=377,
unreach=0, hmode=3, pmode=4, hpoll=10, ppoll=10, headway=0, flash=00 ok,
keyid=0, offset=0.145, delay=0.096, dispersion=15.187, jitter=0.142,
xleave=0.052,
filtdelay=     0.10    0.10    0.05    0.08    0.09    0.11    0.11    0.11,
filtoffset=    0.14    0.16    0.19    0.12    0.02   -0.02   -0.04   -0.10,
filtdisp=      0.00   15.57   31.37   47.42   63.65   79.41   95.27  110.72

然而，我们偶尔会看到系统抖动增加很多。深入研究后，我们发现延迟和偏移值出现了一次跳跃。示例：

filtdelay=     0.06    0.11  250.20    0.07    0.04    0.10    0.07    0.09,
filtoffset=    0.05   -0.01  124.95   -0.05   -0.05   -0.07   -0.05   -0.03,

请注意，在这种情况下offset（通常但总是）保持在 0.5/-0.5 以内：

# ntpq -pn
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
*10.10.10.249    10.10.100.20     3 u  711 1024  377    0.112   -0.006  47.230

有时高抖动值会持续几个小时，大部分时间保持不变。较大的抖动量从 1 到 100 以上不等。最终它会降回 1 以下。

附录 我们发现系统负载和 NTP 抖动之间存在关联。初步猜测，NTP 数据包可能与 NFS 流量发生冲突。

编辑 这不是 GPS 时钟源。

编辑 这肯定是个问题。我们看到的抖动大致与高偏移值相关。

答案1

根据我在 JPL 的 Mars 2003 项目中的经验，当时我负责软件锁相环，该环使地面航天器模拟与航天器下行链路时钟信号保持同步，混叠是我能想到的唯一可能导致瞬时抖动的现象。当时间信号客户端认为信号“滴答”代表什么与它实际代表什么之间失去关联时，就会发生混叠。如果您的客户端（问题中的“我的服务器”）在连接中断后使用抗混叠算法尝试重新同步，则可能需要一段时间才能重新同步。

Mars'03 时钟信号为 8Hz，这意味着每秒有 8 个信号。如果客户端的采样时间落后超过 1/8 秒，那么它将错过其中一个信号并感到困惑。为了解决这个问题，我让锁相环尽可能坚固和有弹性，这样在正常情况下它几乎不可能与传入信号失去同步。如果它确实失去同步（除非我使用示波器强制它，否则我从未见过它这样做），它必须重新开始，等待众所周知的同步模式进入，然后它可以重置锁相环，就像在启动时一样。

根据这一经验，我猜测您的瞬时抖动是由时间同步网络上的瞬时连接丢失引起的，如果您的时间协议像 TCP/IP 一样保证交付，则数据包风暴可能会加剧这种情况。如果保证交付的协议落后于时钟信号，则会导致混叠。然后，客户端必须尽一切努力重新同步，在这种情况下尝试保证交付可能会引发数据包风暴，使情况变得更糟，然后才能好转。如果抗混叠逻辑足够合理，那么您可能需要检查您的时间协议是使用 TCP/IP（保证交付）还是 UDP（不保证交付但更精简），并使用 UDP 来消除数据包风暴。

相关内容