ntpd与如何实现可靠的NTP同步？

Question

当我使用ntpdc -c sysinfo查询NTP守护进程的状态时，会得到以下输出：

system peer:          0.0.0.0
system peer mode:     unspec
leap indicator:       11
stratum:              16
precision:            -20
root distance:        0.00000 s
root dispersion:      12.77106 s
reference ID:         [73.78.73.84]
reference time:       00000000.00000000  Thu, Feb  7 2036  7:28:16.000
system flags:         auth monitor ntp kernel stats
jitter:               0.000000 s
stability:            0.000 ppm
broadcastdelay:       0.000000 s
authdelay:            0.000000 s

这表示NTP同步失败。然而，在1秒的精度内，系统时间是精确的。当我在同一时期没有网络连接的情况下运行我的系统时，系统时间会偏离10秒。

这种行为表明系统有另一种同步时间的方法。我意识到还有systemd-timesyncd.service (配置文件位于/etc/systemd/timesyncd.conf)，timedatectl status给了我正确的时间：

      Local time: Thu 2016-08-25 10:55:23 CEST
  Universal time: Thu 2016-08-25 08:55:23 UTC
        RTC time: Thu 2016-08-25 08:55:22
       Time zone: Europe/Berlin (CEST, +0200)
     NTP enabled: yes
NTP synchronized: yes
 RTC in local TZ: no
      DST active: yes
 Last DST change: DST began at
                  Sun 2016-03-27 01:59:59 CET
                  Sun 2016-03-27 03:00:00 CEST
 Next DST change: DST ends (the clock jumps one hour backwards) at
                  Sun 2016-10-30 02:59:59 CEST
                  Sun 2016-10-30 02:00:00 CET

所以我的问题是，这两种机制有什么区别？他们中有人反对吗？它们能并行使用吗？当我要查询NTP同步状态时，我应该信任哪一个？

(请注意，我有一个不同的系统(在不同的网络中)，这两种方法都表示成功并产生正确的时间。

Answer 1

系统时间同步不遵守时钟规则:时钟没有经过训练或补偿，内部时钟随时间漂移也没有减少。调整投票间隔有基本的逻辑，但如果没有约束，主持人最终将永远处于不平衡的时间状态，因为系统时间同步(Systemd Timesyncd)按它认为的短期漂移所需的时间间隔推拉。它也不能评估远程时间源的质量。你不太可能获得超过100毫秒的准确度。对于像笔记本电脑这样简单的终端用户设备来说，这已经足够了，但是它肯定会给需要更高的时间精度的分布式系统带来问题。