标签: clock

观察：
我有一台配备 AMD 双核 CPU (Turion II Neo N40L) 的 HP 服务器，它可以将频率从 800 扩展到 1500 MHz。频率缩放适用于 FreeBSD 9 和带有 Linux 内核 3.5 的 Ubuntu 12.04。但是，当我将 FreeBSD 9 放在 Ubuntu 之上的 KVM 环境中时，频率缩放不起作用。来宾（因此是 FreeBSD）不会检测最小和最大频率，因此当 CPU 占用率更高时不会扩展任何内容。在主机（即 Ubuntu）上，KVM 进程使用了​​ 80% 到 140% 的 CPU 资源，但没有发生频率缩放，频率保持在 800 MHz，尽管当我在同一个 Ubuntu 机器上运行任何其他进程时，按需调节器很快将频率缩放到 1500 MHz！

关注和问题：
我不明白 CPU 是如何虚拟化的，以及是否由来宾执行适当的缩放。是否需要向来宾公开某些 CPU 功能才能使其工作？

Apendix：
在下面的Red Hat发布说明倾向于认为，频率缩放出来工作，即使在虚拟化环境中（参见第6.2.2和6.2.3），认为注未能解决其虚拟化技术与（KVM，Xen的这项工作， 等等。？）

有关信息，cpufreq-infoUbuntu 上的输出为：

$ cpufreq-info
cpufrequtils 007: cpufreq-info (C) Dominik Brodowski 2004-2009
Report errors and bugs to cpufreq@vger.kernel.org, …

我有一个运行精简版 Ubuntu 的（物理）盒子；时不时地（3 个月内 6 次），时钟向后跳正好 300 秒（+- 0.01 秒；总是正好 300 秒）。它从一分钟到下一分钟发生（我有一台外部机器每分钟轮询一次）。

该盒子正在运行 2.6.26-generic（自定义编译内核）、Ubuntu 9.04（我知道，我正在尝试更新它，但它是半嵌入式的）。日志中没有任何内容表明发生了什么，而且我有大量的 pool.ntp.org ntp 服务器可供选择，它们会在一段时间后更正问题。

有谁知道这可能导致什么？

附加 1：

我还有许多其他机器运行相同的内核（二进制相同），以及相同软件的微小变化，它们没有这个问题。我也换了硬件。

附加 2（我个人评论的摘要）：

• 我知道 9.04 已经过时了，我同意它应该更新，这个决定是我无法控制的。因为管理。
• 我尝试了大量的ntp 服务器，也尝试了少量的。在这两种情况下它仍然会发生；如果我有大量的 ntp 服务器，那么它会更快地自我修复。
• 我已经换掉了硬件
• 我在另一个机器上使用相同的内核/操作系统（具有相同的硬件），但没有显示问题。
• 重新启动没有帮助。（这个问题已经持续了大约6个月）
• 正常运行时间约为 3 个月。该框“始终打开”，运行 PBX（星号）。
• 现在，hwclock 与软件时钟完全匹配 - 0.000000 秒
• 我找不到任何读取硬件时钟的 cron 作业。
• 没有与负载相关的模式（尽管负载非常低）。
• 它发生在白天和黑夜。
• 它不会定期发生。在过去 3 个月的事件中，有一半发生在过去 9 天。
• 这不是“漂移”——在 99% 的情况下，它在极小的一秒之内，然后从一分钟到下一分钟，它正好向后跳跃 300 秒。所以，一分钟它可能会说是 3:07:03，在 1 微秒内匹配我的另一台计算机，60 秒后，它会说 3:04:03。
• 我在日志中找不到任何东西。

我正在一个由大约 10 台地理位置分散的远程 Linux 计算机组成的网络上进行一些实验。

我怀疑它们中的一些有时钟偏差，但它们是短暂的（例如，一周一次或一个月两次）。

我想知道是否有一些工具可以检测和量化这种时钟偏差。还想知道时钟偏差是否是我所看到的正确术语，或者是否可以称为时钟同步。

我有一个设置为每周一凌晨 1 点运行的 cron

0 1 * * 1 /script/dir/script >> /script/dir/file.log

按预期运行两年后，它在 6 月 18 日运行了两次，第二次调用发生在第一次调用之后的 ½ - 1 秒。什么可能导致这种情况发生？

它不是由人类第一次或第二次运行。

该脚本与网站相关联，但位于文档根目录之外。

时钟是否可能在同一时刻同步，迫使它倒退 1 秒并在凌晨 1 点重新运行 cron？

默认情况下，tmux状态栏时钟粒度似乎设置为 2 秒，但是如果能够将其设置为一秒粒度就更好了。

有没有办法在 a 中设置粒度.tmux.conf？我在man tmux.

在我的 Manjaro linux 机器上，我有一个文件/etc/timezone，其中包含：

Asia/Bangkok

另一个 Manjaro 论坛用户也有相同的文件。该线程总体上包含有关此问题的一些现有技术。

奇怪的是timedatectl status不使用这个文件来报告Region/City. 这是初始状态：

$ timedatectl status                                          
                      Local time: Fri 2018-06-29 11:01:28 +07       
                  Universal time: Fri 2018-06-29 04:01:28 UTC    
                        RTC time: Fri 2018-06-29 04:01:28        
                       Time zone: Asia/Bangkok (+07, +0700)             
       System clock synchronized: no                          
systemd-timesyncd.service active: no                              
                 RTC in local TZ: no                            

现在我/etc/localtime用它指向的文件内容覆盖符号链接：

$ sudo ln -f "$(realpath /etc/localtime)" /etc/localtime          
$ timedatectl status                                           
                      Local time: Fri 2018-06-29 04:04:03 UTC
                  Universal time: Fri 2018-06-29 04:04:03 UTC …

我想以微秒分辨率知道当前系统时间。 date +%s返回自纪元（1-1-1970）以来的时间（以秒为单位）。如何获得以微秒为单位的时间分辨率。查询这个值有多少延迟？延迟我的意思是假设在t我查询的时间秒，它给了我价值t + t'是什么t'？
我的用例：我正在使用多个 Raspberry Pi 模拟录制视频。现在我想为视频的每一帧加上时间戳，以便我可以对齐它们。目前对于时间戳，它使用启动时间（启动后的时间）。启动时间是准确的，但每个 Raspberry Pi 的时间都不同。我已将所有 Pi 配置为 NTP 服务器，因此都具有相同的系统时间。所以基本上我想要系统时间的时间戳而不是启动时间。我怎样才能做到这一点 ？

我最近阅读了很多关于 UNIX Time 的文章，其中大部分内容不连贯，大部分内容相互矛盾。我正在尝试协调 UNIX 时间（以下简称 UXT）、TAI 和 UTC 之间的转换，为此，我需要正确理解 UXT。问题是，我似乎找不到其他人这样做了。

以下是我通过繁琐研究从无数来源重建的最佳解释。也有哪里不对。 我正在寻找对以下内容的整体分析和逐点验证/反驳。本质上，修复以下内容以使其正常工作。

1. TAI 是一个单调递增的时间标准。它滴答 SI 秒，并忽略 DST 和闰秒。

2. UTC 与 TAI 相同，但通过整数个闰 SI 秒进行校正（转换为时间字符串将其反映为第 60 秒），以便在天文时间标准 UT1 的 0.9 SI 秒内。

3. UXT 是自 1970-01-01 00:00:00 UTC 以来的UNIX 秒计数。每天总是正好有 86400 秒。然而，UXT 与 UTC 相关。

4. 这怎么可能？嗯，UNIX 秒需要与 SI 秒不同，并且因为闰秒不是完全规则的，UNIX 秒不能是一个明确定义的时间长度。

5. UNIX 规范第4.15 节中从 UTC 到 UXT 的转换将不同的 UTC 时间别名为相同的 UXT 时间戳，从而有效地使 UNIX 秒与 SI 秒相同（UNIX 闰秒除外，它们是两个 SI 秒）。
   
   在实践中，实际发生的情况各不相同。大多数计算机基于远程服务器进行同步，因此它们在同步期间隐式地处理闰秒更新。

6. 所有这一切意味着，虽然每个单独的 UXT 时间戳都可以轻松转换为 …

我想我可以做这样的事情：

sudo unshare -T bash -c \'date -s "$1" && foobar\' sh "$(date -d -1day)"\n

所以foobar会看到与系统其他部分不同的系统时间。但是，似乎不包含系统时间的变化。它改变了整个系统的系统时间。

这篇 LWN 文章似乎表明这个命名空间是为了我试图赋予它的用途而设计的。

\n

当在根时间命名空间之外调用时，调整系统时间的系统调用将调整特定于命名空间的偏移量。

\n

看着strace date -s ...，我看到了其他输出：

clock_settime(CLOCK_REALTIME, {tv_sec=1619044910, tv_nsec=0}) = 0\n

然而，阅读time_namespaces(7)：

\n

这会影响针对这些时钟进行测量的各种 API，包括：clock_gettime(2)、clock_nanosleep(2)、nanosleep(2)、timer_settime(2)、timerfd_settime(2) 和 /proc/uptime。

\n

我看到它没有提到clock_settime(2)。“包括”一词告诉我这可能不是完整的列表，但也许是。

我也不懂--boottime/ --monotonic。看着clock_settime(2)，我看到：

\n

CLOCK_MONOTONIC 不可设置的系统范围时钟，表示自 \xe2\x80\x94 以来的单调时间，如 POSIX\xe2\x80\x94 所描述的“过去的某个未指定点”。在 Linux 上，该点对应于系统自启动以来运行的秒数。

\n

\n

CLOCK_BOOTTIME（自 Linux …

我正在使用该awful.widget.textclock小部件在 Arch Linux 上的 Awesome WM 中显示时间，并且我正在使用一个称为tzupdate定期根据地理位置自动更新我的系统时间的程序。

我经常出差，所以我认为自动化这个会很好。但是，除非我重新启动 Awesome（或重新登录/重新启动），否则 textclock 小部件不会更改时间。我可以在 lua 脚本中添加一些东西来让小部件刷新时区吗？

tzupdate工作正常。我有一个systemd计时器，每五分钟更新一次时区。系统的时区以这种方式成功更改。timedatectl立即输出显示更新的时区，日期命令的输出正确显示正确的更新本地时间。

但是，如上所述，在我重新启动 ( CtrlModR) 或注销之前，Awesome 无法注意到此时区更改。