w32tm /resync 不能立即工作

Question

这个问题主要是供其他人学习并满足我自己的好奇心，如果有人知道它为什么会这样做。

我们的 DC 有一个问题，因为它被虚拟化了，没有合适的时间，这个问题已经得到解决。但是我们的一些客户端和服务器需要更新的时间。所以我尝试以 admin w32tm /query /source 身份运行以下命令以确保它从我们的域控制器获取时间，然后 w32tm /resync 同步时间，两个命令都没有错误但时间没有改变。

我在事件日志中看到类似于以下行的内容。系统时间从 2014-09-08T21:31:33.342455400Z 更改为 2014-09-08T21:31:33.328000000Z。

所以我在没有改变的情况下再试了几次命令，然后在谷歌上搜索了一下，结果回来发现客户端现在有合适的时间，但事件日志中没有任何新内容。

我在第二个客户端上尝试了相同的结果，但我没有离开客户端，而是在日志周围戳了一下，出于纯粹的运气，我低头看了看时钟，发现时间越来越接近真实时间。它正在缓慢地回到正确的时间。时钟会时不时地上升 2 秒，或者在整整一秒过去之前一秒会变成下一个数字。它会这样做，直到时钟到达正确的时间。

我的问题是为什么要这样做？当我将时间同步到 NTP 服务器时，为什么不像我的个人计算机那样立即将时间更改为正确的时间？

Answer 1

显然这是设计使然：

如果客户端的本地时钟时间比服务器上的时间早不到三分钟，W32Time 会将时钟频率四分之一或减半足够长的时间以使时钟同步。如果客户端提前少于 15 秒，则频率减半；否则，它将四分之一频率。时钟以异常频率运行所花费的时间取决于正在校正的偏移量的大小

http://blogs.msmvps.com/acefekay/2009/09/18/configuring-the-windows-time-service-for-windows-server/

我找不到明确解释其设计原因的参考资料，但我猜想目的是为了避免突然跳跃，以防其他应用程序使用内部时钟来计时操作。因此，如果偏移量较低，则通过调整本地时钟速率来使用“收敛”方法。如果差异为 3 分钟或更长，则 Kerberos 身份验证失败的风险（> 5 分钟时钟差异）被认为比“跳跃”本地时钟所涉及的风险更严重，因此时钟只是重置而不是收敛