@
mengzhuo 我没有说阿里的钟一定是准的,不,我并没有这个意思,将来宣传出现了偏差...
用 GPS 做时间源常见的系统误差来源,可以认为闰秒也算一个,但闰秒是常量所以加上偏移就搞定,而且像你说的,GPS 本身就会下发闰秒信号,不需要接收端特意设置;另一个是从信号接收到内核这一段的传输&软件处理的延迟,这个值在一般设备上很容易达到几百毫秒,而且不同设备不一致,所以需要在架设部署的时候和别的时间源进行校准来确定
还有一块误差来自运行过程中机器自身走时速度不均匀造成的漂移,但阿里用了原子钟守时,原子钟输出的 PPS 频率是足够精确的,不会存在这个问题
如果阿里的钟不准,多半就是这个校准没做好,或者校准后在运行中(软件 /硬件)环境发生变化造成原有的系统误差变大或者变小,而没有再次校准所以偏掉;我随手测了下,和
cn.pool.ntp.org 确实存在误差,分别差大约 -13ms, -45ms, +19ms, 和 +16ms,但 pool 里面这几台延迟都在 200~300ms 水平,会明显影响校时精度,所以实际误差肯定比这个再小一些,你看,pool 的机器自己互相之间误差就这么大了...
$ ntpdate -q
time.pool.aliyun.comserver 120.25.108.11, stratum 2, offset 0.001602, delay 0.05620
server 115.28.122.198, stratum 2, offset -0.000663, delay 0.04390
server 182.92.12.11, stratum 2, offset 0.001149, delay 0.05899
1 Oct 15:05:50 ntpdate[28719]: adjust time server 115.28.122.198 offset -0.000663 sec
$ ntpdate -q
cn.pool.ntp.orgserver 5.79.108.34, stratum 2, offset -0.013887, delay 0.22470
server 108.59.2.24, stratum 2, offset -0.045969, delay 0.37437
server 163.172.177.158, stratum 3, offset 0.019065, delay 0.34531
server 203.135.184.123, stratum 1, offset 0.046475, delay 0.32439
1 Oct 15:06:00 ntpdate[28727]: adjust time server 203.135.184.123 offset 0.046475 sec
另外补个苹果的
$ ntpdate -q
time1.apple.comserver 17.254.0.27, stratum 1, offset -0.038363, delay 0.30672
1 Oct 15:20:01 ntpdate[28892]: adjust time server 17.254.0.27 offset -0.038363 sec
$ ntpdate -q
time2.apple.comserver 17.254.0.28, stratum 1, offset -0.063057, delay 0.32030
1 Oct 15:20:11 ntpdate[28906]: adjust time server 17.254.0.28 offset -0.063057 sec
$ ntpdate -q
time3.apple.comserver 17.254.0.31, stratum 1, offset -0.024707, delay 0.21799
1 Oct 15:20:22 ntpdate[28916]: adjust time server 17.254.0.31 offset -0.024707 sec
$ ntpdate -q
time4.apple.comserver 17.151.16.20, stratum 1, offset -0.003465, delay 0.21930
1 Oct 15:20:37 ntpdate[28926]: adjust time server 17.151.16.20 offset -0.003465 sec
$ ntpdate -q
time5.apple.comserver 17.151.16.21, stratum 1, offset -0.033497, delay 0.23425
1 Oct 15:20:47 ntpdate[28936]: adjust time server 17.151.16.21 offset -0.033497 sec
$ ntpdate -q
time6.apple.comserver 17.151.16.22, stratum 1, offset -0.007614, delay 0.22504
1 Oct 15:20:57 ntpdate[28946]: adjust time server 17.151.16.22 offset -0.007614 sec
时间一致性比 pool 的要好一些,但自身之间还是有 10ms 数量级的误差(股沟家的我这边查都是 v6 给数据 v4 没结果,多半是墙,考虑到之前曾经遇到 v4/v6 不同栈误差高达 100ms 的情况,就不贴了,原因怀疑是骨干网路由走向不同)
我想表达的是,你贴的那段原文只是讲了 UTC 时间和 GPS 时间有个闰秒的偏差,和阿里的钟为啥不准完全是两个事情,至于你认为可能来自硬件实现的系统误差,且不说这个误差在初次校准的时候就会被改正回来,以及阿里显然用的商用授时硬件而不是几百块的玩具,这样直接猜测对方硬件实现不精密和你指责 @
refactor 报 bug 不写补丁有本质区别么?
讲真,想要精确授时,搞个(最好两个) GPS 接随便什么 ARM 寨版装随便什么 Linux 发行版,放在内网拿时间戳,再用 GPS 自带的 PPS 信号守时,初始校准随便找 pool 之类的公网机器观察几小时就行,授时精度通常都在 1ms 左右,1u 上因为有 PPS 信号可以达到 100ns 级别的精度甚至更高,jitter 可以直接是 0 ;和隔开几百毫秒的网络时间源同步,光本地 ISP 线路抖动带来的随机误差就差不多能有 10ms 量级了,你看 ntpq -p 的输出里面 jitter 是不是经常都好几毫秒甚至好几十毫秒......
ps, 我原来以为报 bug 只要把现象说清楚就行了,原来还要修复彻底的?