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 以上）。
2017-10-02 16:07:19 +08:00 回复了 mengzhuo 创建的主题 › 云计算 › 发现 aliyun 的 ntp 不够准确啊 |
"多年看空难调查给我的教训是，一切要以事实数据为准绳，而他一直在扯其他的，也不肯公布数据。"
数据和事实放在楼主面前，楼主也不知道数据和事实的意义的。
“多年看空难调查给我的教训” 这个装逼，只是一个笑话。
数据和事实放在楼主面前，楼主也不知道数据和事实的意义的。
“多年看空难调查给我的教训” 这个装逼，只是一个笑话。
2017-10-02 16:05:02 +08:00 回复了 mengzhuo 创建的主题 › 云计算 › 发现 aliyun 的 ntp 不够准确啊 |
“仅仅指出了 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 本身有所谓“精读”，“时钟误差”？
请问楼主，怎么计算 这个 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 本身有所谓“精读”，“时钟误差”？
2017-10-02 15:55:34 +08:00 回复了 mengzhuo 创建的主题 › 云计算 › 发现 aliyun 的 ntp 不够准确啊 |
不好意思，刚才在 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 是怎么测量的？什么是“时钟误差”？怎么测量的？
本来不想打脸楼主的，楼主非要装逼。
正好国庆有点时间，回复一下。
看代码，其中计算并且输出的结果：
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 是怎么测量的？什么是“时钟误差”？怎么测量的？
Select Language