refactor 最近的时间轴更新 refactor 最近的时间轴更新 |
refactorV2EX 第 54786 号会员，加入于 2014-01-22 21:54:32 +08:00 |
| 开发人员Mac OS X的常见设置 MacBook Pro • refactor • 2014-01-22 22:57:17 PM • 最后回复来自 ReSur | 40 |
refactor 最近回复了
2017-10-03 22:43:47 +08:00 回复了 mengzhuo 创建的主题 › 云计算 › 发现 aliyun 的 ntp 不够准确啊 |
@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:
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:
2017-10-02 21:19:12 +08:00 回复了 mengzhuo 创建的主题 › 云计算 › 发现 aliyun 的 ntp 不够准确啊 |
再贴一下我们的时钟源上面的数据：
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 的误差对于
绝大多数的日常应用，精读是足够了。
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 的误差对于
绝大多数的日常应用，精读是足够了。
2017-10-02 21:03:27 +08:00 回复了 mengzhuo 创建的主题 › 云计算 › 发现 aliyun 的 ntp 不够准确啊 |
apple，google 是直接使用 stratum 1 的，微软、阿里，都是使用 stratum 2 对外服务的。
现在成本倒不是第一位的，主要假设天线、或者设置原子钟同步比较麻烦。而 ntp 这个协议，使用 stratum 2 的精读已经足够了。误差主要不是这个引起的，误差主要是网络质量引起的。
现在成本倒不是第一位的，主要假设天线、或者设置原子钟同步比较麻烦。而 ntp 这个协议，使用 stratum 2 的精读已经足够了。误差主要不是这个引起的，误差主要是网络质量引起的。
2017-10-02 21:01:14 +08:00 回复了 mengzhuo 创建的主题 › 云计算 › 发现 aliyun 的 ntp 不够准确啊 |
我们是用树莓派做了两个 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
上面是我们两个时钟源，设置了权限的。
给服务器组提供服务的，不是直接通过 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
上面是我们两个时钟源，设置了权限的。
2017-10-02 20:37:17 +08:00 回复了 mengzhuo 创建的主题 › 云计算 › 发现 aliyun 的 ntp 不够准确啊 |
这也是 ntp pool 为什么要按照地区来设置服务器，比如：
asia.pool.ntp.org
cn.pool.ntp.org
而你目前设置的几个服务器，只有腾讯的 IP 123.206.216.158 ，加入了
大陆和亚洲的 pool。而其余的 IP 使用的是海外的 vps，并没有加入 cn.pool.ntp.org ，
也没有为大陆的用户服务。
asia.pool.ntp.org
cn.pool.ntp.org
而你目前设置的几个服务器，只有腾讯的 IP 123.206.216.158 ，加入了
大陆和亚洲的 pool。而其余的 IP 使用的是海外的 vps，并没有加入 cn.pool.ntp.org ，
也没有为大陆的用户服务。
2017-10-02 20:31:44 +08:00 回复了 mengzhuo 创建的主题 › 云计算 › 发现 aliyun 的 ntp 不够准确啊 |
所以结论应该是：
aliyun、Google、Apple 等的 ntp 服务器都是准确的，
都是使用的相同的时钟源，
都是使用的相同的 ntp 协议。
在大陆，应该尽量使用大陆的 ntp 服务器（比如 aliyun 的 ntp ），
减少网络质量导致的 ntp 时间同步误差。
aliyun、Google、Apple 等的 ntp 服务器都是准确的，
都是使用的相同的时钟源，
都是使用的相同的 ntp 协议。
在大陆，应该尽量使用大陆的 ntp 服务器（比如 aliyun 的 ntp ），
减少网络质量导致的 ntp 时间同步误差。
2017-10-02 20:22:54 +08:00 回复了 mengzhuo 创建的主题 › 云计算 › 发现 aliyun 的 ntp 不够准确啊 |
对不起，刚才几个回复，火药味有点重。
谢谢你为大家提供的这个 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 以上）。
谢谢你为大家提供的这个 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 以上）。
Select Language