V2EX › AstroProfundis 的所有回复 › 第 19 页 / 共 71 页

V2EX = way to explore

V2EX 是一个关于分享和探索的地方

现在注册

已注册用户请登录

1 ... 15 16 17 18 19 20 21 22 23 24 ... 71

❮

❯

2017 年 11 月 6 日

回复了 xjr1022 创建的主题 › 程序员 › 200m 宽带下 wifi 下载速度满值最多 10M 每秒

啊楼主这个应该就是路由器没有千兆口的锅，顺便想起我自己折腾的时候遇到的一个问题，线有瑕疵造成光猫到路由器之前偶尔协商成百兆，所有硬件都是千兆的，从路由器的 kernel log 里面才看出来问题，然后调整线和链接之后就稳定多了

2017 年 10 月 27 日

回复了 daiqiangbudainiu 创建的主题 › MacBook Pro › 终端下有啥好用的字体吗？

Source Code Pro

2017 年 10 月 20 日

回复了 xiaome 创建的主题 › 游戏 › 《文明Ⅲ：完整版》steam 喜加一，限时免费领取

领完发现我的库里面已经有了 233333

2017 年 10 月 11 日

回复了 a251922581 创建的主题 › Python › Linux 源安装的 Python3.4.3 版本，刚刚下载编译了官网的 Python3.6.3 版本，装上后 Python3 就挂了提示 No module named 'readline'之类

另外如果你用的 root, configure 时候没指定 prefix 然后直接 make install 怕是把系统的给覆盖了？

2017 年 10 月 8 日

回复了 JiPhone 创建的主题 › 程序员 › 开通招行 young 卡后,需要注意哪些东西?

第一件事，发信用卡照片的时侯把姓名、卡号和有效期都涂掉

2017 年 10 月 4 日

回复了 baskice 创建的主题 › 问与答 › 公司内流量控制如何识别完全没特征的混淆流量？

既然是公司内控，这就不是个技术问题，所以解决当事人才是正确办法
比如发个通知说清楚情况并辅以相关管理措施之类的

2017 年 10 月 4 日

回复了 nladuo 创建的主题 › 分享创造 › 冬天又要到了，自己动手 DIY 一个 PM2.5 检测仪把！

想过自己做，但讲真就算做出来了也不敢把数字直接放出来，到时候一句没有资质违法 XX 就能怼死...

2017 年 10 月 1 日

回复了 mengzhuo 创建的主题 › 云计算 › 发现 aliyun 的 ntp 不够准确啊

哦不错苹果也有 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

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

2017 年 10 月 1 日

回复了 mengzhuo 创建的主题 › 云计算 › 发现 aliyun 的 ntp 不够准确啊

@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 只要把现象说清楚就行了，原来还要修复彻底的？

2017 年 9 月 30 日

回复了 mengzhuo 创建的主题 › 云计算 › 发现 aliyun 的 ntp 不够准确啊

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

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

2017 年 9 月 26 日

回复了 opengps 创建的主题 › 问与答 › 今天提交工单时候发现阿里云的一个故障公告，修复不修复受限于运营商

@opengps 不不，不是运营商，运营商只是干活的，甚至直接干活都不一定是运营商的人（

2017 年 9 月 26 日

回复了 akrislu 创建的主题 › 宽带症候群 › 为什么我的阿里云总被掐

@akrislu 对就是这样.......最近只要那谁一那啥就会来一波，阿里云只是其中一部分......

2017 年 9 月 26 日

回复了 opengps 创建的主题 › 问与答 › 今天提交工单时候发现阿里云的一个故障公告，修复不修复受限于运营商

根据路由跟踪分析，异常节点处于跨境互联出口处
如果您的业务因此受到影响（海外客户访问正常），建议您清查您的业务中是否包含违规信息或违规服务，或尝试更换服务器并迁移服务

都说得这么明白了还能怎样 =_/=