我有一个嵌入式 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 秒的差距。无论如何，出于以下原因，我并不认为这只是一个巧合。
当我看到它持续上升时，我做了一些挖掘。关联命令的输出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 秒），所以我认为这是一个巧合的想法似乎得到了支持。
答案1
您的客户端拒绝与服务器同步，因为其“根弥散”（服务器自己对与“真实”时间之间的误差的估计，也是影响对等距离的变量之一）约为 2.2 秒，大于一秒的默认容忍度。
尽管最好调试服务器并找出为什么它对自己的计时能力有如此糟糕的估计，但您可以通过为tos maxdistntp.conf 中的选项提供更大的值来强制客户端与其同步。