引用https://wiki.archlinux.org/title/System_time:
大多数操作系统的标准行为是:
- 在启动时从硬件时钟设置系统时钟。
- 保持系统时钟的准确时间,请参阅#时间同步。
- 在关机时从系统时钟设置硬件时钟。
谁负责在关机时从系统时钟设置硬件时钟的最后一步?
引用https://wiki.archlinux.org/title/System_time:
大多数操作系统的标准行为是:
- 在启动时从硬件时钟设置系统时钟。
- 保持系统时钟的准确时间,请参阅#时间同步。
- 在关机时从系统时钟设置硬件时钟。
谁负责在关机时从系统时钟设置硬件时钟的最后一步?
在无数次查找如何使用gettimeofday()
时,我决定这次快速深入了解 vDSO,因为我对它只有模糊的认识,并想知道是否有任何我应该注意的使用陷阱。
根据https://stackoverflow.com/questions/42622427/gettimeofday-not-using-vdso ,如果vDSO正在使用中,strace
则不应显示or 。gettimeofday
clock_gettime
好吧,看起来我的 ThinkPad T400 已经坏了一段时间了:从我记事起,我就一直看到*吨*的这些电话strace
。(特别是来自 QEMU。)
如果我从上述问题尝试testgtod.c
(运行1000 次):gettimeofday()
$ strace ./testgtod 2>&1 | grep clock_gettime | wc -l
1000
目前,我能在 ThinkPad 和 i3 桌面之间找到的唯一区别是 i3 使用 TSC,而 ThinkPad 使用 HPET,因为tsc: Marking TSC unstable due to TSC halts in idle
. (想知道这是否可能是暂停/恢复的事情,但随后注意到时间戳 - 这是启动后的 1.53 秒。)T400(当前......)运行 Arch,而 i3 机器运行 Debian 9。
上面的问题也提到了dump-vdso.c
。T400 上的 vDSO 对我来说看起来不错:
$ objdump -T vdso.so
vdso.so: file format elf64-x86-64
DYNAMIC SYMBOL TABLE:
0000000000000740 w DF .text 000000000000005e LINUX_2.6 clock_gettime
00000000000007a0 g DF .text 0000000000000067 LINUX_2.6 __vdso_gettimeofday
00000000000007a0 w DF .text 0000000000000067 LINUX_2.6 gettimeofday
0000000000000810 g DF .text 0000000000000010 LINUX_2.6 __vdso_time
0000000000000810 w DF .text 0000000000000010 LINUX_2.6 time
0000000000000740 g DF .text 000000000000005e LINUX_2.6 __vdso_clock_gettime
0000000000000000 g DO *ABS* 0000000000000000 LINUX_2.6 LINUX_2.6
0000000000000820 g DF .text 0000000000000025 LINUX_2.6 __vdso_getcpu
0000000000000820 w DF .text 0000000000000025 LINUX_2.6 getcpu
我发现的另一个链接https://bert-hubert.blogspot.com/2017/03/on-linux-vdso-and-clockgettime.html表示 vDSO 代码缺乏对某些计时器的支持,并将回退到系统调用,如果你使用其中之一。那篇文章来自 2017 年,https://lore.kernel.org/linux-arm-kernel/[email protected]/(2019 年 6 月)中的详细信息表明几乎所有(如果不是全部? ) 计时器现在支持 vDSO,但无论如何,testgtod
上面提到的程序称为CLOCK_REALTIME
,2017 年的文章说当时支持 vDSO。
所以:我正式感到困惑:)
通过http://btorpey.github.io/blog/2014/02/18/clock-sources-in-linux/阅读,我看到很多对 TSC 的引用。这篇文章并没有真正提到它,但我开始认为这可能RDTSC{,P}
是一个可以从用户空间调用的非特权指令,而从 HPET 读取需要内核级访问(对硬件或计时器值)。这将完全解释系统调用回退。
顺便说一句,我的 T400 中的 Core2 P8600 确实支持tsc
and constant_tsc
,但不支持nonstop_tsc
。
tsc gettimeofday clock-gettime vdso hpet 都不存在,如果有更多声誉的人想要添加其中的一个或多个。
我遇到了chonyd
服务器日期的问题。
我将硬件时钟日期从当前的实际日期mar. nov. 27 15:57:12 CET 2018
更改为mer. déc. 12 12:12:12 CET 2012
使用以下命令:
hwclock --set --date="12/12/2012 12:12:12"
hwclock -s
我使用 启动 chronyd 服务systemctl start chronyd
,并使用 检查状态systemctl status chronyd
,这是显示chronyd
服务运行正常的输出:
● chronyd.service - NTP client/server
Loaded: loaded (/usr/lib/systemd/system/chronyd.service; enabled; vendor preset: enabled)
Active: active (running) since mer. 2012-12-12 12:20:14 CET; 27min ago
...
déc. 12 12:20:17 pad chronyd[1808]: Selected source 178.32.220.7
déc. 12 12:20:17 pad chronyd[1808]: System clock wrong by 188017778.899985 seconds, adjustment started
déc. 12 12:25:37 pad chronyd[1808]: Selected source 62.210.211.218
这是/etc/chrony.conf
配置文件:
# Record the rate at which the system clock gains/losses time.
driftfile /var/lib/chrony/drift
# Enable kernel synchronization of the real-time clock (RTC).
rtcsync
# Enable hardware timestamping on all interfaces that support it.
hwtimestamp *
# Specify directory for log files.
logdir /var/log/chrony
server 0.fr.pool.ntp.org minpoll 0 maxpoll 0
server 1.fr.pool.ntp.org minpoll 0 maxpoll 0
server 2.fr.pool.ntp.org minpoll 0 maxpoll 0
server 3.fr.pool.ntp.org minpoll 0 maxpoll 0
这是启动chronyc sources
后的输出chronyd
:
^+ obelix.fraho.eu 2 0 377 0 -876us[ -876us] +/- 12ms
^- bb8.dousse.eu 2 7 377 40 -1547us[-1547us] +/- 52ms
^- cdg1.m-d.net 2 6 377 39 -806us[ -806us] +/- 33ms
^* cluster004.linocomm.net 2 7 377 100 +330us[ +384us] +/- 7957us
输出表明服务器已连接,显示ntp 主机服务器的^+
字符。obelix.fraho.eu
60 多分钟后,我date
在终端中运行命令并得到以下输出:
mer. déc. 12 13:15:04 CET 2012
chronyd 尚未更新日期...
文件夹/var/log/chronyd/
为空
任何想法 ?