发现 aliyun 的 ntp 不够准确啊

2017-09-30 11:07:23 +08:00
 mengzhuo

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

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

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

下面是跑脚本 3 次的结果,代码我附在最后

time2.aliyun.com,28.655746ms
time3.aliyun.com,26.759582ms
time5.aliyun.com,29.008967ms
time6.aliyun.com,22.483205ms
time1.google.com,302.125µs
time2.google.com,154.277µs
time3.google.com,942.302µs
time1.apple.com,128.849µs
time2.apple.com,150.666µs
time3.apple.com,46.247µs
time4.apple.com,263.644µs
time5.apple.com,196.309µs
time6.apple.com,28.467µs
time3.aliyun.com,25.598556ms
time5.aliyun.com,29.037168ms
time6.aliyun.com,14.518584ms
time1.google.com,0s
time2.google.com,1.146204ms
time2.apple.com,0s
time3.apple.com,0s
time4.apple.com,0s
time6.apple.com,0s
time1.aliyun.com,14.320869ms
time2.aliyun.com,26.738995ms
time3.aliyun.com,26.47347ms
time4.aliyun.com,26.599685ms
time5.aliyun.com,28.720771ms
time1.google.com,66.609µs
time2.google.com,129.603µs
time3.google.com,438.115µs
time1.apple.com,-91.208µs
time2.apple.com,121.155µs
time3.apple.com,-142.25µs
time4.apple.com,61.033µs
time5.apple.com,81.492µs
time6.apple.com,-171.77µs

https://gist.github.com/mengzhuo/8acbd88b71d0a88c6844a22f0f39093f

14419 次点击
所在节点    云计算
43 条回复
zlfzy
2017-09-30 11:13:28 +08:00
这东西要求精确到毫秒级别啦
psfang
2017-09-30 11:15:25 +08:00
膜拜大佬。dig 一下阿里云的 2,3,4,会发现 ip 是一样的。。
ZenFX
2017-09-30 11:18:37 +08:00
Windows 下 time.windows.com 有时总是失败,就改成了 time.pool.aliyun.com ,速度是挺快的,现在还有什么靠谱的推荐吗?
mengzhuo
2017-09-30 11:21:32 +08:00
@psfang #2
这我竟然没有注意到,关键是知乎的帖子里有个哥们说 aliyun 的时钟源是北斗和 GPS,我个人猜测是被厂商坑了。
https://www.zhihu.com/question/30252609
mengzhuo
2017-09-30 11:21:56 +08:00
mengzhuo
2017-09-30 11:23:25 +08:00
@zlfzy #1

NTP 本身就是设计成可以不管多少层都控制在 10ms 以下的误差
likuku
2017-09-30 11:24:25 +08:00
@ZenFX time.apple.com 一直很好用。碰过的 windows,第一件事就是 ntp 服务器改成 time.apple.com
zhihaofans
2017-09-30 12:19:19 +08:00
苹果亚洲的 ntp 服务器不是挺好的吗
rebbie
2017-09-30 12:27:53 +08:00
麻烦楼主贴下 pool.ntp.org 的结果。详细参考:
http://www.pool.ntp.org
mengzhuo
2017-09-30 13:50:03 +08:00
@rebbie #9

pool 的什么机器都有的,而且每次解析也不一样的
Lisp
2017-09-30 13:58:41 +08:00
refactor
2017-09-30 14:00:50 +08:00
楼主的代码有问题。

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

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

为了验证楼主代码的问题,将:

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

改成

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

也就是将基准时间改成 aliyun 的,发现结果也是一样,说 aliyun 和 aliyun 有误差。
这就说明楼主测试方法或者 代码有问题了。
mengzhuo
2017-09-30 14:41:00 +08:00
@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.
pynix
2017-09-30 14:52:09 +08:00
ntp 怎么解决同步期间网络延迟?
openbsd
2017-09-30 14:56:45 +08:00
唉,还是因为穷啊
我朝 国家授时中心 服务器还时常连不上呢
mengzhuo
2017-09-30 15:01:02 +08:00
@pynix #14

看 RFC 5905,里面有介绍
psfang
2017-09-30 16:10:07 +08:00
@pynix 之前写过一个简单介绍,http://fangpeishi.com/ntp_problem.html
@mengzhuo 求大佬有空 review,看看有没有错,这块不太熟悉=。=
xierch
2017-09-30 18:50:03 +08:00
@mengzhuo 按他这段话的意思,这个 GPS 的 UTC offset 会有好几秒吧?
AstroProfundis
2017-09-30 21:33:55 +08:00
@xierch
@mengzhuo 你贴的那个是闰秒,现在应该是差 37 秒还是多少来着,和这个几十毫秒的误差两回事

#12 楼 @refactor 说的问题我觉得楼主可以看一眼...
mengzhuo
2017-10-01 00:01:27 +08:00
@AstroProfundis

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

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

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

这是一个专为移动设备优化的页面(即为了让你能够在 Google 搜索结果里秒开这个页面),如果你希望参与 V2EX 社区的讨论,你可以继续到 V2EX 上打开本讨论主题的完整版本。

https://www.v2ex.com/t/394813

V2EX 是创意工作者们的社区,是一个分享自己正在做的有趣事物、交流想法,可以遇见新朋友甚至新机会的地方。

V2EX is a community of developers, designers and creative people.

© 2021 V2EX