Linux与Windows系统之间的时间同步问题

Linux与Windows系统之间的时间同步问题

我有一台 Windows 7 和两台 Linux(Ubuntu 16.04)计算机(W1、L1 和 L2),它们通过 WiFi 连接 - 遗憾的是无法使用有线连接。Linux 计算机运行 chrony 进行时间同步,L1 设置为 L2 上的源,运行正常。时钟应尽可能接近,50 毫秒的偏移已经会开始造成问题。但对于使用 chrony 的 Linux 系统来说,这完全没有问题。现在我还必须将 W1 上的时间同步到 L1,不幸的是 Windows 没有可用的 chrony。所以我用这个脚本将 L1 IP 作为对等体:https://gist.github.com/thedom85/dbeb58627adfb3d5c3af 一次性同步有效,但也存在一些缺陷:

  1. 迄今为止最成问题的是:Windows 系统上的时间与 Linux 时间的偏差非常快。平均偏差约为每 10 分钟 1 秒。简单的解决方案 - 只需频繁重新同步时钟 - 由于问题 2 和 3 而不起作用
  2. 在 Windows 系统上,只有当时间主表存在较大时间偏移时,同步才会成功。如果只有几秒钟,则不会发生同步。
  3. 在 Windows 系统上,只有在运行脚本,然后断开 WiFi 连接并重新连接后,同步才会生效。时钟会在重新建立连接的那一刻跳转。

有什么方法可以解决这些问题,或者有更好的方法吗?不幸的是,我无法将所有时钟都引导到一些高精度互联网计时服务器或 GPS 时间,因为至少 Windows 系统从未连接到互联网,而 Linux 系统也不能依赖其互联网连接。起初,我以为问题 1 可能是由 chrony 引导 L1 时钟引起的,但在初始同步后停用 chrony 似乎对这个问题没有任何影响。

以下是一些显示该问题的图片。W1 不断向 L2 发送带有当前 L1 时间的消息,L2 在到达时添加其时间戳,该图显示了 L2 观察到的两个时间戳之间的差异。 在此处输入图片描述

编辑:L1 和 L2 均由电池供电 - 两者均由同一电源供电。由于仅 CMOS 电池应负责 RTC,因此我认为这不会造成任何问题。然而事实证明确实如此。通过交流电为这些计算机供电(因此交流电 -> 交流/直流转换器 -> 计算机,而不是电池 -> 直流/直流转换器 -> 计算机)可显著减少漂移。但这还不够好: 在此处输入图片描述

编辑2:解决方案/解决方法 我禁用了糟糕的 Windows 时间服务 (w32time),并安装了Linux NTP 程序的移植相反。通过相当激进的轮询率设置,这可以正常工作: 在此处输入图片描述

相关内容