标签: time

在所有基于 linux 的数据中心中检测时间漂移的策略是什么？这是一个比起初看起来更困难的问题。

时间漂移可能会导致某些应用程序出现严重问题，并且通常即使安装了 NTP，也可能由于以下（以及更多）原因而失败：

• NTP 未正确设置为在重新启动时自动重新启动。
• 服务器上的设置不正确，因此它指向的时间服务器无法访问或不准确。
• 主时间服务器无法访问，所有与其同步的服务器现在都同步到不可靠的源。

我想要一种方法来检测所有单个服务器是否正确。请记住，带有测试脚本/应用程序的服务器可能不正确。

在 6.0.8 Debian 服务器 (HP ProLiant) 冷启动后ntpd，系统时间受到严重破坏：相对于无限制增长的通常且可靠的参考时间服务器的偏移和抖动。（请注意，两个相同的服务器根本没有问题。）在多次尝试解决问题失败后，ntpd我决定尝试重新启动，一切顺利。

为了调查这个问题，我发现了这个差异，这可以解释我的时钟问题：

root@n1:~# zgrep Detected /var/log/dmesg*
/var/log/dmesg:[    0.004000] Detected 2400.110 MHz processor.
/var/log/dmesg.0:[    0.004000] Detected 2383.579 MHz processor.
/var/log/dmesg.1.gz:[    0.004000] Detected 2400.036 MHz processor.
/var/log/dmesg.2.gz:[    0.004000] Detected 2400.298 MHz processor.
/var/log/dmesg.3.gz:[    0.004000] Detected 2400.165 MHz processor.
/var/log/dmesg.4.gz:[    0.004000] Detected 2400.410 MHz processor.

请注意，在第二次启动（有问题的启动）中，检测到的 CPU 频率是一个明显的异常值。在没有异常值的情况下，检测到的频率相对于标称频率的误差和标准偏差为 +0.15 MHz ± 0.25 MHz。对于有问题的启动，我的错误为 -16.4 Mhz，比预期大 100 倍。

我的问题：

1. 这种类型的错误会使ntp时间规则不稳定/无法使用吗？这是我的时钟问题的原因吗？

2. 这种类型的行为是硬件不稳定的症状吗？服务器是否应该进行硬件维护？

更新

一些有用的数据：

• 内核是 2.6.32-5-amd64（Debian 2.6.32-48squeeze4）
• current_clocksource 是 tsc
• 错误lpj（当然）与 …

看起来有两个选项可以为 DHCP 客户端提供网络时间设置；option 004 和 option 042。004 的描述是“时间服务器”，而 042 指定的是 NTP。是否有理由使用其中之一，或者仅仅是供应商偏好？如果客户端使用选项042，选项002中的时间偏移是否仍然使用？

使用时间 C 函数（自 Epoch 以来的秒数）显示，与具有正确时间的另一台服务器相比，我当前的 CentOS 6 服务器上的时间大约晚了 7 小时。如何更正系统时钟？我不认为这是漂移，因为我几周前刚刚设置了这个服务器，但它可能是。我设置了 ntpd 但它没有帮助，可能是因为时差太大。

我有一个简单的任务：设置一个 ToD 服务器......它不是 NTP。它在端口 37 上运行。它似乎与 inetd 或 xinetd 捆绑在一起。

应安装在 Debian 或 CentOS 上。或者 FreeBSD（pfsense 路由器）。

有关如何进行的任何提示？我被卡住后的两个起始链接：

• http://www.linuxquestions.org/questions/linux-server-73/tod-server-641674/
• http://en.wikipedia.org/wiki/Time_Protocol

如果有一种方法来测试 ToD 服务器是否正在运行，也非常感谢。我有很多服务器在运行，但不知道是否有任何服务器已经运行了 ToD 服务

原因：我将使用 CMTS 和电缆调制解调器使用称为 DOCSIS 3 的标准设置通过同轴电缆宽带的解决方案。为此，电缆调制解调器需要从 ToD 服务器（时间）接收时间。

更新/解决方案

时间是RFC 868，几乎不再使用，因为 NTP 和其他更好。但是某些系统需要旧的 RFC 868 端口 37 时间 - 例如，使用 CMTS 的同轴电缆上的互联网和电缆调制解调器需要一个工作时间服务器（在 DOCSIS 文档中称为时间服务器 = ToD 服务器）。可以为 Debian 安装的 xinetd 包括一个时间服务器。它只需要在 etc/xinetd.d/time 中启用（对于 TCP 和/或 UDP 禁用=否）

你如何处理服务器时间漂移？

对于相对较大的网络（数千台主机） - 支持和反对运行本地管理（池）NTP 服务器（可能通过某些公共 NTP 服务器定期设置）并让网络上的所有其他主机使用的论据是什么？那个（池）NTP 服务器与让所有主机直接使用公共 NTP 服务器（比如通过 ntp.pool.org）？

除了利弊之外，当今典型的最佳实践是什么？

我的系统使用 UTC 作为系统时钟，我并不特别想改变它。有没有一种简单的方法可以获取当前的 TAI 时间？（最好是命令行工具或标志）

在尝试使用 NTD 或手动使用date命令设置服务器时间时，我遇到了一个有趣的问题。

首先，我尝试使用 NTD。我已经成功安装了最新版本的 NTD，并启动了它。在那之后，我希望同步开始。这就是我运行以下命令的原因：ntpdate pool.ntp.org

我收到了以下错误：

5 月 18 日 15:29:21 ntpdate[15477]：step-systime：不允许操作

比我不知道该怎么做，所以我尝试使用以下date命令手动设置时间：

rm /etc/localtime
ln -s /usr/share/zoneinfo/GMT /etc/localtime
date 051822172013

但是我收到了这个错误：

日期：无法设置日期：不允许操作

谁能猜出我的服务器上可能出现的问题是什么？我以 root 身份登录，并且使用 CentOS 5。

谢谢你。

是否有一种现有的机制可以在在线时将 linux 系统与 NTP 同步，并在离线时与可预测的漂移 RTC 同步？

我们操作远程“收集器”：收集和时间戳传感器数据的嵌入式 Linux 系统。我们需要他们的时钟误差保持在相当小的范围内，比如低于 5 秒。通常我们使用 NTP 来同步他们的时钟，只要系统在线，就可以正常工作。

问题是一些收集器的上行链路非常糟糕，可能会中断数小时、数天甚至数周。这不会停止本地数据收集，但如果没有 NTP，Linux 系统时钟漂移严重且不可预测。

OTOH，硬件的 RTC 漂移也很大，但速率恒定。RTC 漂移率因板而异，但每块板都是恒定的，并且可以测量。

我想我们需要的是一种执行以下操作的机制：

• 在部署前测量电路板的 RTC 漂移率
• 如有可能，通过 NTP 持续/定期调整系统时间
• 当 NTP 不可用时，从 RTC 定期调整系统时间。考虑已知的 RTC 漂移率。
• 可选：在线测量并记录实时 RTC 漂移率 (1)

对于“机制”，我指的是一些维护良好、记录在案的软件和/或配置，可以处理“在线”与“离线”两种状态，确保系统时钟与正确的时间源（ntp 与 ntp 与 ntp 同步）。 rtc)，检测状态变化，并校正 RTC 漂移。无论是作为特殊的 ntpd 配置/插件、作为单独的守护程序、作为 cron 作业还是其他方式实现，都没有多大关系。

我看过Chrony，但根据它的文档，它试图预测系统时钟的漂移，在我们的例子中，它的漂移比 RTC 更难以预测。Chrony 似乎只使用 RTC 来保持重新启动的时间。

(1) 注意 ntpd 激活内核的“11 分钟模式”（每 11 分钟从系统时钟更新 rtc）。当前的内核和 ntpd 似乎没有办法阻止 11 分钟模式。因此，任何 rtc 漂移信息在 ntpd …