跳到正文

发现 aliyun 的 ntp 不够准确啊

网友提供43 条回复

因为楼主自己有写了 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

回复

mengzhuo

@AstroProfundis

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

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

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

AstroProfundis

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

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

xierch

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

psfang

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

mengzhuo

@pynix #14

看 RFC 5905,里面有介绍

openbsd

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

pynix

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

mengzhuo

@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.

refactor

楼主的代码有问题。

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

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

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

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

改成

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

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

Lisp

time.apple.com.

mengzhuo

@rebbie #9

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

rebbie

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

zhihaofans

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

likuku

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

mengzhuo

@zlfzy #1

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

mengzhuo

@ZenFX #3

cn.pool.ntp.org

mengzhuo

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

ZenFX

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

psfang

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

zlfzy

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

↑