问尽管在引导前NTP同步，系统时间却被关闭了数百毫秒。

EN

我最初的反应是，300毫秒似乎太多了，但我确实有数字要做，它们表明@Law29是对的：

1. 我的一台正常一周的机器：
   • 频率：

- System peer offset: 

1. 相同的系统，较短的重新启动周期：
   • 频率：

- System peer offset: 

- Scatter plot of the peers 

(希望你能读懂图表上的所有数字--如果不是，请给我一个注释。)

正如你所看到的，有一个相当大的差异。这让我感到惊讶的是，它是如此之多，也是花了这么长的时间回到轨道上的频率校正，考虑到在我的本地网络有一个1层GPS源。而且，考虑到对等样本在图中的聚集性相当紧密，这显然是本地时钟的一个问题，而不是启动过程中不一致的网络延迟。(记录在案，硬件是一台穿梭梭437无扇迷你PC，配有双核Celeron1037U@ 1.8 GHz。)

所以外卖很可能是：

1. 确保ntpd成功地编写了NTP漂移文件，
2. 确保内核更新硬件时钟的11分钟计时器已开启(请参阅man hwclock中的“内核自动硬件时钟同步”以获取详细信息)，否则您的关闭过程正在更新硬件时钟，
3. 确保ntpd具有4-10个可达源 (在iburst模式下)，以及
4. 配置您的启动依赖项，以便ntpd有机会在Paxos启动之前修复时钟。

我没有要生成的数字，但是用于在引导时设置时钟的接口很可能只具有精确到第二个的精度。

您没有声明您的操作系统，但是在所有类似Unix的系统上，可以在引导过程中插入对NTP时间的依赖。

NTP守护进程是在启动时启动的，但通常它会立即启动并继续启动，而NTP守护进程则查找要同步的服务器--这样就不会在机器没有连接到网络的情况下延迟启动。

在本例中，您将希望确保ntp守护进程的启动方式将通过逐步启动纠正偏移量。例如，这可以是ntpd -gx或chronyc -q。您还可能希望在开始工作负载之前插入一项检查，以确保偏移量是可以接受的。