为什么 NTP 认为我的服务器不足？

Question

我有一个嵌入式 Linux 设备通过 USB/Net 接口直接连接到我的 Windows 桌面。它基于 Freescale iMX6 板，因此我相信时钟硬件是 SNVS RTC。

在桌面上192.0.0.10，我将 W32Time 作为 NTP 服务器运行，并且嵌入式设备192.0.0.100（我认为）已正确配置为根据ntp.conf文件使用它：

server 192.0.0.10 iburst minpoll 5 maxpoll 7
driftfile /data/ntp.drift
restrict default nomodify nopeer noquery limited kod
restrict 127.0.0.1
restrict [::1]

连接不是问题^(a)，因为我可以在嵌入式设备上执行：

ntpdate -uq 192.0.0.10
ntpdate -ub 192.0.0.10

这将成功查询并更新时间。

然而，我发现应该保持同步的时钟ntpd漂移了很多。我ntpd大约 18 小时前开始并同步，偏移逐渐上升到大约 5 秒：

     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
 192.0.0.10      192.168.0.4      4 u   31   32  377    1.452  4941.57  11.927

在过去的几个小时里，它实际上已经开始恢复，但距离应有的水平还差 3.2 秒。无论如何，我不相信这只是巧合，原因如下。

当我看到它持续上涨时，我做了一些挖掘。Associations 命令的输出过去ntpq是（现在仍然是）：

# ntpq -c as

ind assid status  conf reach auth condition  last_event cnt
===========================================================
  1 62876  9024   yes   yes  none    reject   reachable  2

这似乎表明，尽管服务器可以访问，但由于某种原因正在被过滤。根据状态9024（请参阅此处），它似乎可以用“因无效而丢弃（TEST10-TEST13）”来解释。

那么，然后我去查看ntpq该关联的变量：

# ntpq -c rv 62876

associd=62876 status=9024 conf, reach, sel_reject, 2 events, reachable,
srcadr=192.0.0.10, srcport=123, dstadr=192.0.0.100, dstport=123, leap=00,
stratum=4, precision=-6, rootdelay=129.150, rootdisp=2193.741,
refid=192.168.0.4,
reftime=ddd30907.eff60ee5  Thu, Dec  7 2017  0:25:43.937,
rec=ddd31287.4db24cd8  Thu, Dec  7 2017  1:06:15.303, reach=377,
unreach=0, hmode=3, pmode=4, hpoll=5, ppoll=5, headway=21,
flash=400 peer_dist, keyid=0, offset=3186.569, delay=1.446,
dispersion=16.036, jitter=11.844, xleave=0.093,
filtdelay=     1.45    1.42    1.41    1.47    1.44    1.43    1.44    1.48,
filtoffset= 3186.57 3189.58 3192.08 3194.56 3197.13 3199.58 3202.57 3205.06,
filtdisp=     15.63   16.12   16.60   17.08   17.58   18.06   18.54   19.03

我看到该flash变量被设置为400基于上面链接的同一页面显示0400/TEST11/peer_dist/peer distance exceeded。

现在我认为这不是物理距离（客户端和服务器都在我的桌面上）或网络距离（两个设备直接连接）。我在网上找到的唯一有用的参考资料是Google 网上论坛，其中一位 David Woolley 指出：

超出距离意味着最坏情况往返时间引起的误差和自根服务器上的最后有效时间（加上一些次要组件）以来假设的 15ppm 漂移的组合已超过 1 秒。

这种情况通常发生在已同步一次但仍会漂移的 w32time 服务器上。如果服务器处于孤立模式，并且很长时间没有实时源，并且您没有使用最新的孤立模式代码，也可能会发生这种情况。

不幸的是，我不知道如何计算“最坏情况往返时间引起的错误”，所以我不知道如何从这里继续。我非常确定我的桌面正在与公司时间服务器同步（我的桌面和其他一些桌面的时间似乎都非常接近），尽管我也不确定如何重点检查这一点。

所以，我的问题是，我可以从这里去哪里？我似乎无法从中获取任何更有用的信息ntpq，甚至ntpd -dd在前台运行似乎也无法弄清楚为什么服务器时间被拒绝。

任何帮助将不胜感激。

---

^(a)正如 Windows 端的日志进一步指出的，通过以下方式启用：

w32tm /debug /enable /file:C:\w32time.log /size:10000000 /entries:0-300

并生产：

152281 02:06:57.1968483s - ListeningThread -- DataAvailEvent set for socket 1 (0.0.0.0:123)
152281 02:06:57.1973483s - ListeningThread -- response heard from 192.0.0.100:123 <- 192.0.0.10:123
152281 02:06:57.1973483s - /-- NTP Packet:
152281 02:06:57.1973483s - | LeapIndicator: 3 - not synchronized;  VersionNumber: 4;  Mode: 3 - Client;  LiVnMode: 0xE3
152281 02:06:57.1973483s - | Stratum: 0 - unspecified or unavailable
152281 02:06:57.1973483s - | Poll Interval: 5 - 32s;  Precision: -20 - 953.674ns per tick
152281 02:06:57.1973483s - | RootDelay: 0x0000.0000s - unspecified;  RootDispersion: 0x0000.F1A0s - 0.943848s
152281 02:06:57.1973483s - | ReferenceClockIdentifier: 0x494E4954 - source name: "INIT"
152281 02:06:57.1973483s - | ReferenceTimestamp:   0x0000000000000000 - unspecified
152281 02:06:57.1973483s - | OriginateTimestamp:   0xDDD320A033087D7D - 13157085984199348300ns - 152281 02:06:24.1993483s
152281 02:06:57.1973483s - | ReceiveTimestamp:     0xDDD3209D4DB18BA5 - 13157085981303490400ns - 152281 02:06:21.3034904s
152281 02:06:57.1973483s - | TransmitTimestamp:    0xDDD320BE4D535D3F - 13157086014302053300ns - 152281 02:06:54.3020533s
152281 02:06:57.1973483s - >-- Non-packet info:
152281 02:06:57.1973483s - | DestinationTimestamp: 152281 02:06:57.1973483s - 0xDDD320C132856B0E152281 02:06:57.1973483s -  - 13157086017197348300ns152281 02:06:57.1973483s -  - 152281 02:06:57.1973483s
152281 02:06:57.1973483s - | RoundtripDelay: -562900ns (0s)
152281 02:06:57.1973483s - | LocalClockOffset: -2895576400ns - 0:02.895576400s
152281 02:06:57.1973483s - \--
152281 02:06:57.1973483s - TransmitResponse: sent 0.0.0.0:123(192.0.0.10:123)->192.0.0.100:123

---

更新评论“在过去的几个小时里，它实际上开始回来了”：它实际上又开始漂移（目前为 3.7 秒），所以我认为这是巧合的想法似乎得到了支持。

Answer 1

您的客户端拒绝与服务器同步，因为它的“根分散”（服务器自己根据“真实”时间估计的误差，以及影响对等距离的变量之一）约为 2.2 秒，这大于默认容差为一秒。

虽然最好调试服务器并找出为什么它对自己的计时能力的估计如此糟糕，但您可以通过为tos maxdistntp.conf 中的选项提供更大的值来强制客户端与其同步。