V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
V2EX  ›  AstroProfundis  ›  全部回复第 17 页 / 共 69 页
回复总数  1365
1 ... 13  14  15  16  17  18  19  20  21  22 ... 69  
2017-10-04 13:53:31 +08:00
回复了 baskice 创建的主题 问与答 公司内流量控制如何识别完全没特征的混淆流量?
既然是公司内控,这就不是个技术问题,所以解决当事人才是正确办法
比如发个通知说清楚情况并辅以相关管理措施之类的
2017-10-04 13:48:33 +08:00
回复了 nladuo 创建的主题 分享创造 冬天又要到了,自己动手 DIY 一个 PM2.5 检测仪把!
想过自己做,但讲真就算做出来了也不敢把数字直接放出来,到时候一句没有资质违法 XX 就能怼死...
2017-10-01 15:44:52 +08:00
回复了 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-01 15:38:25 +08:00
回复了 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-09-30 21:33:55 +08:00
回复了 mengzhuo 创建的主题 云计算 发现 aliyun 的 ntp 不够准确啊
@xierch
@mengzhuo 你贴的那个是闰秒,现在应该是差 37 秒还是多少来着,和这个几十毫秒的误差两回事

#12 楼 @refactor 说的问题我觉得楼主可以看一眼...
@opengps 不不,不是运营商,运营商只是干活的,甚至直接干活都不一定是运营商的人(
2017-09-26 11:37:01 +08:00
回复了 akrislu 创建的主题 宽带症候群 为什么我的阿里云总被掐
@akrislu 对就是这样.......最近只要那谁一那啥就会来一波,阿里云只是其中一部分......
根据路由跟踪分析,异常节点处于跨境互联出口处
如果您的业务因此受到影响(海外客户访问正常),建议您清查您的业务中是否包含违规信息或违规服务,或尝试更换服务器并迁移服务

都说得这么明白了还能怎样 =_/=
2017-09-26 11:27:08 +08:00
回复了 akrislu 创建的主题 宽带症候群 为什么我的阿里云总被掐
这不是阿里云的锅,你说没做违法的事情,但问题是某些组织可能并不认为 IPSec 不违法

至于究竟是违了什么法...出门左转找 XX
2017-09-20 21:42:53 +08:00
回复了 fhefh 创建的主题 分享发现 联通流量红包,需要在联通营业厅 App 中领取
领了 200M
必需三天内激活,当月有效,不转结,感觉是用不到了...
2017-09-04 18:07:44 +08:00
回复了 v2xiaohao 创建的主题 职场话题 日常取名贴,求个阿里花名,真不好想啊!
你需要 /t/258771
2017-08-30 17:41:30 +08:00
回复了 siyiye 创建的主题 Google Google 发来贺电:您的帐号已被停用
我在脚本里每次重试之间加上了一个 1-3 秒的随机 sleep...
2017-07-15 04:11:28 +08:00
回复了 Hanggi 创建的主题 云计算 阿里云你不管干什么都要收费,这样好吗?
挺好的吖,养活了多少开发者
2017-07-06 00:21:02 +08:00
回复了 ruanmeibi 创建的主题 奇思妙想 人人微信以后的时代——邮箱?
邮箱比 QQ 微信 XMPP 啥的历史悠久多了........
2017-07-05 13:50:31 +08:00
回复了 terrytw 创建的主题 SSL 遇到一个奇葩网站
连接 oa.sphchina.com 时发生错误。 在服务器密钥交换握手信息中 SSL 收到了一个弱临时 Diffie-Hellman 密钥。 错误代码: SSL_ERROR_WEAK_SERVER_EPHEMERAL_DH_KEY
2017-07-05 13:37:11 +08:00
回复了 liwusen00 创建的主题 杭州 V 友吗,杭州还适合生活吗?毕业生是选择杭州还是成都
成都人现在在杭州,但不一定会完全定居,过几年可能想法会变
反正没钱买房╮( ̄▽ ̄")╭
2017-07-02 19:12:02 +08:00
回复了 Jaosn 创建的主题 Apple MacBook Pro 一觉醒来被猫咬了怎么办?
被主子 mark 认证了,说明你买到了好东西
2017-07-02 03:35:10 +08:00
回复了 WhyLiam 创建的主题 问与答 收到的邮件内容被篡改了
对于一般意义的邮件来说,PGP/GnuPG 是标准答案,但看了楼主最后的说明感觉...
嗯...打印出来亲自跑一趟吧...
2017-06-16 11:35:22 +08:00
回复了 hello123vvv 创建的主题 问与答 请问如何指检查 SSL 证书的到期时间?
check_http
1 ... 13  14  15  16  17  18  19  20  21  22 ... 69  
关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   1032 人在线   最高记录 6679   ·     Select Language
创意工作者们的社区
World is powered by solitude
VERSION: 3.9.8.5 · 42ms · UTC 19:58 · PVG 03:58 · LAX 11:58 · JFK 14:58
Developed with CodeLauncher
♥ Do have faith in what you're doing.