发现 aliyun 的 ntp 不够准确啊

这东西要求精确到毫秒级别啦

膜拜大佬。dig 一下阿里云的 2，3，4，会发现 ip 是一样的。。

Windows 下 time.windows.com 有时总是失败，就改成了 time.pool.aliyun.com ，速度是挺快的，现在还有什么靠谱的推荐吗？

@psfang #2
这我竟然没有注意到，关键是知乎的帖子里有个哥们说 aliyun 的时钟源是北斗和 GPS，我个人猜测是被厂商坑了。
https://www.zhihu.com/question/30252609

@ZenFX #3

cn.pool.ntp.org

@zlfzy #1

NTP 本身就是设计成可以不管多少层都控制在 10ms 以下的误差

@ZenFX time.apple.com 一直很好用。碰过的 windows，第一件事就是 ntp 服务器改成 time.apple.com

苹果亚洲的 ntp 服务器不是挺好的吗

麻烦楼主贴下 pool.ntp.org 的结果。详细参考：
http://www.pool.ntp.org

@rebbie #9

pool 的什么机器都有的，而且每次解析也不一样的

time.apple.com.

楼主的代码有问题。

我们自建了两台 NTP，使用 GPS 授时。

用楼主的代码跑了一下，误差和 aliyun 的一样的。

为了验证楼主代码的问题，将：

nist, err = ntp.Query("time.nist.gov")

改成

nist, err = ntp.Query("time1.aliyun.com")

也就是将基准时间改成 aliyun 的，发现结果也是一样，说 aliyun 和 aliyun 有误差。
这就说明楼主测试方法或者 代码有问题了。

@refactor #12

看来如果接收机不计算 UTC offset 的话，可能会导致时间源不准确。

https://www.nist.gov/pml/time-and-frequency-division/nist-time-frequently-asked-questions-faq

What is GPS time?
.... Since GPS time does not adjust for leap seconds, it is ahead of UTC(USNO) by the integer number of leap seconds that have occurred since January 6, 1980 plus or minus a small number of nanoseconds. However, the time offset from UTC is contained in the GPS broadcast message and is usually applied automatically by GPS receivers.

ntp 怎么解决同步期间网络延迟？

唉，还是因为穷啊
我朝 国家授时中心 服务器还时常连不上呢

@pynix #14

看 RFC 5905，里面有介绍

@pynix 之前写过一个简单介绍，http://fangpeishi.com/ntp_problem.html
@mengzhuo 求大佬有空 review，看看有没有错，这块不太熟悉=。=

@mengzhuo 按他这段话的意思，这个 GPS 的 UTC offset 会有好几秒吧？

@xierch
@mengzhuo 你贴的那个是闰秒，现在应该是差 37 秒还是多少来着，和这个几十毫秒的误差两回事

#12 楼 @refactor 说的问题我觉得楼主可以看一眼...

@AstroProfundis

仔细读一下原文，
GPS 在广播信息里带有偏移值
而如何计算是__接收器__决定的，万一两个都是劣质硬件产品呢？

12 楼的方法是确信 GPS 是准确的时钟源
而且阿里云自己的服务器之间也差不少，我回头补上 Refid 看看是不是同一台服务器。

而且，说我代码、计算方法有问题，至少要指出在哪里。

@mengzhuo
1、GPS 是目前除了原子钟以外最准确的时钟源。也是大多数 NTP 服务器的时钟源。

2、12 楼中，我已经贴出了说明你问题的逻辑：

就是将基准时间从 time.nist.gov 改成 time1.aliyun.com 的，
这时，你的程序竟然说说 aliyun 和 基准有误差，也就是 aliyun 和 aliyun 的 ntp 之间有误差。

至于代码，我没有时间去阅读和修改错误了。

以前都是使用的 asia.pool.ntp.org 以后试试苹果的 time.apple.com

@refactor
Talk is cheap, show me the code.

@mengzhuo 我没有说阿里的钟一定是准的，不，我并没有这个意思，将来宣传出现了偏差...

用 GPS 做时间源常见的系统误差来源，可以认为闰秒也算一个，但闰秒是常量所以加上偏移就搞定，而且像你说的，GPS 本身就会下发闰秒信号，不需要接收端特意设置；另一个是从信号接收到内核这一段的传输&软件处理的延迟，这个值在一般设备上很容易达到几百毫秒，而且不同设备不一致，所以需要在架设部署的时候和别的时间源进行校准来确定

还有一块误差来自运行过程中机器自身走时速度不均匀造成的漂移，但阿里用了原子钟守时，原子钟输出的 PPS 频率是足够精确的，不会存在这个问题

如果阿里的钟不准，多半就是这个校准没做好，或者校准后在运行中（软件 /硬件）环境发生变化造成原有的系统误差变大或者变小，而没有再次校准所以偏掉；我随手测了下，和 cn.pool.ntp.org 确实存在误差，分别差大约 -13ms, -45ms, +19ms, 和 +16ms，但 pool 里面这几台延迟都在 200~300ms 水平，会明显影响校时精度，所以实际误差肯定比这个再小一些，你看，pool 的机器自己互相之间误差就这么大了...

$ ntpdate -q time.pool.aliyun.com
server 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.org
server 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.com
server 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.com
server 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.com
server 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.com
server 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.com
server 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.com
server 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 只要把现象说清楚就行了，原来还要修复彻底的？

哦不错苹果也有 pool 域名

$ ntpdate -q time.apple.com
server 17.253.82.125, stratum 1, offset -0.118363, delay 0.32236
server 17.253.68.253, stratum 1, offset -0.087254, delay 0.28787
server 17.253.84.253, stratum 1, offset 0.031281, delay 0.12460
server 17.253.68.125, stratum 1, offset -0.092504, delay 0.29269
server 17.253.82.253, stratum 1, offset -0.125195, delay 0.34073
1 Oct 15:43:08 ntpdate[29096]: adjust time server 17.253.68.253 offset -0.087254 sec

这个延迟和标准差自己看吧...公网授时这个精度差不多就到头了，高精度要求的只能自己想办法在内网搭建时间源

@AstroProfundis
可能有些误解，我只是很反感那个哥们说的 Aliyun 和 GPS 一定是对的。多年看空难调查给我的教训是，一切要以事实数据为准绳，而他一直在扯其他的，也不肯公布数据。
而且我并没有说过任何关于高精度授时的要求，仅仅指出了 Aliyun 跟 NIST 之间的 ClockOffset 差值问题。这点我的数据说明了 Google 和 Apple 做得很好，三个独立的数据源都指向相同的结果，而 Aliyun 是不同，简单的可以认为是不准确。
Aliyun 的 pool 机器只是 Stratum 2, 意味着这个误差也可能来自他们和 1 之间。
没有 Aliyun 技术说明之前，谁都只能猜这个误差来源。

Ntp Pool 都是志愿者的机器，实现方法可能有 ntpd,openntpd，大大小小的厂商，自然还有我这种爱好者写的和提供的山寨服务。

本来不想打脸楼主的，楼主非要装逼。
既然楼主非要凑上来，正好国庆有点时间，回复一下。

看代码，其中计算并且输出

io.WriteString(os.Stdout,
fmt.Sprintf("%s,%s\n", fmt.Sprintf(t.formater, i+1),
ao.ClockOffset.Truncate(nist.ClockOffset).String()))






"因为楼主自己有写了 ntp 服务，顺带跑 ntp 集群，国内的就近使用了 aliyun 的公共服务，结果发现在 ntp.org 上总是有 50ms 左右的误差。

一开始怀疑的是自己写的代码有问题，但其他节点都在 10ms 以下的精度了，所以就怀疑到了 aliyun 本身的时钟误差，然后发现果然慢了 20ms 左右。

所以大家可以抛弃 aliyun 的 ntp，换 Google 或者 Apple 的都比 aliyun 准确"

不好意思，刚才在 web 上写的时候，敲到一半，一个回车就将草稿发出去了。

本来不想打脸楼主的，楼主非要装逼。
正好国庆有点时间，回复一下。

看代码，其中计算并且输出的结果：

io.WriteString(os.Stdout,
fmt.Sprintf("%s,%s\n", fmt.Sprintf(t.formater, i+1),
ao.ClockOffset.Truncate(nist.ClockOffset).String()))

楼主告诉我，这端逻辑是什么？

我看了一下 github.com/beevik/ntp，其中 ClockOffset 的定义：

// ClockOffset is the estimated offset of the client clock relative to
// the server. Add this to the client's system clock time to obtain a
// more accurate time.
ClockOffset time.Duration

func offset(org, rec, xmt, dst ntpTime) time.Duration {
// local clock offset
// offset = ((rec-org) + (xmt-dst)) / 2
a := rec.Time().Sub(org.Time())
b := xmt.Time().Sub(dst.Time())
return (a + b) / time.Duration(2)
}

这个 ClockOffset 就是 楼主测试的机器，和 ntp 服务器之间的偏差。
那么下面的语句怎么能够计算阿里云 ntp 所谓“精读”，“时钟误差”？

ao.ClockOffset.Truncate(nist.ClockOffset).String())

这里的 Truncate 是 time.Duration 定义的，是最近 golang 才新引入的功能：

func (Duration) Truncate
func (d Duration) Truncate(m Duration) Duration
Truncate returns the result of rounding d toward zero to a multiple of m. If m <= 0, Truncate returns d unchanged.

也就是进行类似 Round 取整的一个方法。

除了代码混乱，再看看楼主文字的装逼：

"因为楼主自己有写了 ntp 服务，顺带跑 ntp 集群"，楼主告诉我，你写了什么 ntp 服务？
ntp 服务传统的有 ntp server，新的有 chrony 等，
看楼主对 ntp 协议的理解和小学生一样的代码功力，楼主的 ntp 服务是什么鬼东东？

什么叫 “ ntp 集群”？不是堆砌一些所谓“集群”就显得高大上的，只会说明你不懂，弄一些名字装逼。

"但其他节点都在 10ms 以下的精度了，所以就怀疑到了 aliyun 本身的时钟误差，然后发现果然慢了 20ms 左右”

楼主告诉我，什么叫“精度”？ 10ms 是怎么测量的？什么是“时钟误差”？怎么测量的？

“仅仅指出了 Aliyun 跟 NIST 之间的 ClockOffset 差值问题”。

请问楼主，怎么计算 这个 ClockOffset 差值问题 的？

我稍微修改了一下楼主的代码，也就是打印出了本机和 ntp 之间的偏差：


for _, t := range targetList {
ali := make([]*ntp.Response, t.count)
for i := 1; i < t.count; i++ {
ali[i-1], err = ntp.Query(fmt.Sprintf(t.formater, i))

if err != nil {
log.Print(err)
continue
}
}

for i, ao := range ali {
if ao == nil {
continue
}
io.WriteString(os.Stdout,
fmt.Sprintf("%s,%s\n", fmt.Sprintf(t.formater, i+1),
ao.ClockOffset.String()))
}
}
io.WriteString(os.Stdout,
fmt.Sprintf("time.nist.gov,%s\n", nist.ClockOffset.String()))


测试结果是：

time1.aliyun.com,4.227168ms
time2.aliyun.com,1.670959ms
time3.aliyun.com,-1.099697ms
time4.aliyun.com,-342.332µs
time5.aliyun.com,-1.607457ms
time6.aliyun.com,2.42408ms
time2.apple.com,-50.105272ms
time4.apple.com,-53.9727ms
time5.apple.com,-53.62832ms
time6.apple.com,-21.437529ms
time.nist.gov,-4.326476ms

这样才是偏差，而不是使用 Truncate 将两个偏差去胡乱计算一下。

从这里可以看出，和 aliyun，nist 的偏差都在 10ms 以内，和 apple 的偏差反而是 50ms 左右。

但是注意的是，这里的偏差并不是 ntp 服务器本身和标准时间的偏差，而是测试机 和 ntp 之间的偏差，这个偏差有两部分组成：

-- 测试机时钟的偏差
-- 网络和计算上引入的偏差，因为 ntp 是通过网络同步的

楼主告诉我，你仅仅通过 ntp 去读取一下，怎么可以判定 ntp 本身有所谓“精读”，“时钟误差”？

"多年看空难调查给我的教训是，一切要以事实数据为准绳，而他一直在扯其他的，也不肯公布数据。"

数据和事实放在楼主面前，楼主也不知道数据和事实的意义的。

“多年看空难调查给我的教训” 这个装逼，只是一个笑话。

@refactor #30

首先，算法问题，
假设真实时间为 a 且我假定 nist 的时间为真实时间
我运行脚本的机器时间为 b
aliyun 的时间为 c
那 aliyun 和 nist 之间的 clockoffset 差为？
(a-b) - (c-b) = a-c
这道加法问题你还能想不出来？

再说 Truncate，确实是没看过文档想当然了。
现在 gist 改过后，再次跑的结果如下：

time1.aliyun.com,13.335629ms
time5.aliyun.com,26.958865ms
time6.aliyun.com,12.378866ms
time1.google.com,-610.225µs
time2.google.com,-718.174µs
time3.google.com,-2.286346ms
time1.apple.com,-581.431µs
time2.apple.com,-763.91µs
time3.apple.com,-580.033µs
time4.apple.com,-613.852µs
time5.apple.com,-780.782µs
time6.apple.com,-617.045µs


最后说我装逼的集群，在这里
http://www.pool.ntp.org/user/cwyn7v2bradopbcenvggk

集群运行状态在这里，6 台破服务器顶日均上 4 亿请求
https://gontpd.org

代码在这里
https://github.com/mengzhuo/gontpd



P.s. 你总是攻击我，说我装逼，可惜的是自然的规律不会因为你我哪个嘴炮强就改变的。我有错就改了，你呢？

对不起，刚才几个回复，火药味有点重。

谢谢你为大家提供的这个 ntp pool 服务。

但是，你的算法和判断确实有问题：

那 aliyun 和 nist 之间的 clockoffset 差为：
(a-b) - (c-b) = a-c

从字面上，看似正确的，但是要明白，这个计算出来的 aliyun 和 nist 之间的 offset，
并不是实际上两个 ntp 时钟的 offset，而是由于 ntp 协议本身的限制，通过 ntp 协议计算出来的 offset。

两者都是标准时间，都是从 原子钟或者 ntp 同步的，都是标准时间。但是通过 ntp 来计算两者之间的 offset，
就会有差异。越是网络条件差，误差越大。也正由于这个原因，严肃的校时场合，是不能用 ntp 作为时钟源的。

因为 aliyun 和 nist 跨越中美互联，所以 10 多毫秒的误差是不足为奇的。

也正由于这个原因，需要在大陆增加一些 ntp 服务器，这样能够减少校时的误差。之前，我们也做过尝试和努力，
设置了一些 ntp 服务器，加入 ntp pool。

但是 ntp pool 有一个机制，需要检测同步的质量，如果失败会导致打分（ score ）下降，踢出 ntp pool。而检测服务器都在美国，目前中美网络条件下，导致检测经常失败，从而 score 达不到标准。我在 ntp pool 邮件列表里面也提过几次，增加大陆的监测服务器，后来还是不了了之。

所以大陆不是没有人热心去做，而是做了 ntp 服务器，也加入不了 ntp pool。

我看到你的几个服务器，除了腾讯上海的，其余都是 linode，vultr 等海外的云主机，所以加入 ntp pool 不是问题，但是对于中国大陆的用户，同步时间导致的误差，还是大了一些。

而 aliyun 的 ntp 在大陆，他们是和原子钟或者 gps 同步的，大陆的用户通过 aliyun ntp 同步的 offset 误差可以控制在 5ms 以内，比通过海外 ntp 同步的误差要小了好多（一半要 20ms 以上）。

所以结论应该是：

aliyun、Google、Apple 等的 ntp 服务器都是准确的，
都是使用的相同的时钟源，
都是使用的相同的 ntp 协议。

在大陆，应该尽量使用大陆的 ntp 服务器（比如 aliyun 的 ntp ），
减少网络质量导致的 ntp 时间同步误差。

这也是 ntp pool 为什么要按照地区来设置服务器，比如：

asia.pool.ntp.org
cn.pool.ntp.org

而你目前设置的几个服务器，只有腾讯的 IP 123.206.216.158 ，加入了
大陆和亚洲的 pool。而其余的 IP 使用的是海外的 vps，并没有加入 cn.pool.ntp.org ，
也没有为大陆的用户服务。

我们是用树莓派做了两个 ntp 时钟源，成本每个控制在 350 元，采用 pps 同步时钟，和标准时间误差在 1~2 us，是 stratum 1。

给服务器组提供服务的，不是直接通过 ntp 直接提供服务的，而是通过 linux 下的 chrony （源头是上述两个树莓派时钟源，所以是 stratum 2 ），这时 offset 已经是 1753 us 了：


$ chronyc sources -v <<<
210 Number of sources = 6

.-- Source mode '^' = server, '=' = peer, '#' = local clock.
/ .- Source state '*' = current synced, '+' = combined , '-' = not combined,
| / '?' = unreachable, 'x' = time may be in error, '~' = time too variable.
|| .- xxxx [ yyyy ] +/- zzzz
|| Reachability register (octal) -. | xxxx = adjusted offset,
|| Log2(Polling interval) --. | | yyyy = measured offset,
|| \ | | zzzz = estimated error.
|| | | \
MS Name/IP address Stratum Poll Reach LastRx Last sample
===============================================================================
^* 61.160.246.234 1 6 377 3 -516us[ -870us] +/- 1753us
^- 61.177.81.162 1 9 377 507 -2543us[+2624us] +/- 4696us
^- hkhkg1-ntp-001.aaplimg.c> 1 10 1 610 -5611us[-1009us] +/- 19ms
^- dns2.synet.edu.cn 2 10 377 796 -2010us[ +347us] +/- 18ms

上面是我们两个时钟源，设置了权限的。

apple，google 是直接使用 stratum 1 的，微软、阿里，都是使用 stratum 2 对外服务的。

现在成本倒不是第一位的，主要假设天线、或者设置原子钟同步比较麻烦。而 ntp 这个协议，使用 stratum 2 的精读已经足够了。误差主要不是这个引起的，误差主要是网络质量引起的。

再贴一下我们的时钟源上面的数据：

gps1% sudo ntpq -pn
remote refid st t when poll reach delay offset jitter
==============================================================================
*127.127.28.0 .GPSD. 1 l 6 16 377 0.000 5.561 2.601
o127.127.22.0 .PPS. 0 l 5 16 377 0.000 0.002 0.005
+61.177.81.162 61.160.246.234 2 u 22 64 377 5.695 -1.591 1.860
-17.253.68.125 .GPSs. 1 u 104 64 12 198.898 -57.311 31.244
+202.112.31.197 202.118.1.47 2 u 28 64 377 49.429 5.075 0.052
-52.173.193.166 128.138.141.172 2 u 112 64 372 231.170 -14.034 34.859

第一行是 gps 同步，误差 5.561 ms，第二行是 pps 校时，误差 2us。

第三行是通过 ntp 和另外一台时钟源校对，误差是 1.591 ms （两个时钟源不在同一个机房）。

第四行是苹果的 17.253.68.125 ，误差是 31.244ms

第五行是 ntp.synet.edu.cn ，误差 5.075ms

第六行是微软的 52.173.193.166 ，误差 34.859ms。

从这个也可以看出，越是国外，网络条件差的，通过 ntp 同步，容易引起时间误差。当然 30~50ms 的误差对于
绝大多数的日常应用，精读是足够了。

这个好像挺复杂

我记得好像 128ms 内的误差 ntp 都认为是可接受的？

哦 记错了 128 只是滑步调整的阈值

@lolizeppelin 是的，ntp FAQ 里面说得很清楚：

http://www.ntp.org/ntpfaq/NTP-s-algo.htm

Of course the final achievable accuracy depends on the time source being used. Basically, no client can be more accurate than its server. In addition the quality of network connection also influences the final accuracy. Slow and non predictable networks with varying delays are very bad for good time synchronization.

A time difference of less than 128ms between server and client is required to maintain NTP synchronization. The typical accuracy on the Internet ranges from about 5ms to 100ms, possibly varying with network delays. A recent survey[2] suggests that 90% of the NTP servers have network delays below 100ms, and about 99% are synchronized within one second to the synchronization peer.

With PPS synchronization an accuracy of 50µs and a stability below 0.1 PPM is achievable on a Pentium PC (running Linux for example). However, there are some hardware facts to consider. Judah Levine wrote:

请问 cn.ntp.org.cn 精度怎么样？和阿里云比？

@stockmaster 差 50ms 左右，主要服务器大部分是志愿者维护的，很多服务还是国外的。不过 cn pool 里有阿里和腾讯的 ntp 服务器，一般用 ntpd 或者 chrony 这类都会自动选到的。