西西河

主题:【求助】不灵了,请弟兄们帮忙 -- 萨苏

共:💬152 🌺15
全看树展主题 · 分页首页 上页
/ 11
下页 末页
家园 应该不是本地路由到ISP线路的问题
家园 还在较劲中

现在看来问题已经锁定在悉尼到墨尔本段的网络上,这一段我们是买的带宽,本来认为不应该有问题的。。。

这些天都在和它折腾呢。

家园 现在一线苦斗的是日本一个号称排名全国第十二的

工程师,并且至少锁定了问题,是属于SLA范围内的事情,感觉和Packet loss有关,究竟是怎么回事,还需要进一步分析。。。

鬼子工程师说:微妙.

兄弟听了这几天终于难得一笑,因为日语里面这两个字的发音太“微妙”了,让人有很糟糕的联想。

家园 这可跟咱说某某“神”不一样di

估计他的发音是

びみょう

而不是

みみょう

但愿老大这个周末能舒舒坦坦的过了

家园 为了不让你们独占带宽使别的用户没法用,路由器会做自动调节的

结论是:不用专用线或有带宽保证的通道没戏。

家园 【注意】搞不懂老萨的物理线路是咋会事...

搞不懂老萨的物理线路是咋会事。需要自己调end-to-end,应该就是两边买了个isp的接入(100兆仪态网,e3啥的)而已,可老萨又说中间买了带宽,好像中间又还是有专线类服务的。

家园 对萨苏所谓“鹿顶红”的考证

生吃的话,跟猴脑可以一拼。

萨苏所说的“鹿顶红”,有两种可能,都是大补之物。一说是鹿茸血。

http://www.tianshannet.com.cn/GB/channel4/117/200511/21/201827.html

另一说,则是砍茸。

http://www.dbzy.net/%5Chtml%5C2005222144031.html

关键词(Tags): #萨苏#马鹿#鹿顶红
家园 又想起了电影《火烧圆明园》

记得里头有咸丰皇帝喝鹿血的镜头,那端的是——喝一口,吐两口啊。

家园 那是签了SLA协议的,否则那ISP可有官司打了

问题要是ISP自身到也还好,

就怕涉及到Telstra或Optus,

那可跟日本的yhaoo和NTT掐架似的,

骨头(backbone)要硬才行呵

家园 不知道协议里有没有带宽保证,如果只有通畅保证依然没戏

一分价钱一分货,人家也不是只做一家的生意,一个通道的带宽毕竟是有限的,他能允许你有带宽峰值,但老占着带宽其他各家的生意就没法做了。

家园 现在的问题已经比较明白了

先解释一下我们的线路,在大阪我们用的是EthernetWan,从大阪到我们的ISP的东京端口,这一段是固定带宽的服务,从对端到我们的ISP的悉尼端口也是EthernetWAN,也是固定带宽的服务,而我们使用的是这家ISP提供的一种叫做DIP的特殊服务,也就是说如果我们购买他们在两端的线路/端口,并且在其上构造InternetVPN,因为在Internet上走的是他们一家的BACKBONE,他们可以给我们提供Latency,packet loss,availibility等一系列SLA,从而保证我们可以达到较好的连接效果.至于带宽,这又是一个微妙的地方,尽管没有SLA,但是基于对自己网络使用状况的了解,ISP承诺在我方使用其网络的某一时间段,可以保证需要的带宽。

这是一个介于专线和普通IPVPN之间的服务,价钱也在其间,但是已经满贵的了。

事实上,我们的测试也表明,ISP的Internet部分并没有带宽问题,无论Upload还是Download都没有问题。这让萨这边松口气,因为如果是这部分出了问题,对方毕竟没有SLA,我们会不太有利。

而这个测试结果让ISP也十分委屈,因为这说明它的确有能力给我们提供承诺的服务,却不知道什么原因背上了黑锅。

进一步的分段测试,得出结论从ISP到对端办公室的线路,虽然按照合同是EthernetWAN,但是表现却没有达到承诺,上传达到26Mbps,下传只有7.2Mbps,我想这是问题的关键,但解决起来并不容易,这一段虽然只有很短,中间的设备却比较复杂,因为我们的ISP实际上也是用其它公司的线路,而不同公司间接口也就比较多,单单比较这些接口的CRC状况就要花费很多时间。

这中间,我们还排除了Host的问题,FW 处理能力的问题,往返路由不一致的可能,Application的Bug,Server的CPU使用率过高,加密通道错误,Sky-X的XTP包出错等问题,时间花的很多,但如同在北京胡同里追捕白宝山,的确不是件很容易的事情。

还在进一步确定问题点中。

家园 从拥塞控制上想想

第二张图好眼熟.兄弟以前做TCP拥塞控制的时候经常看到这样的图形.就大胆猜一下了.

如果网络丢包严重, TCP传送中就会出现这样的锯齿形.因为是有线网,丢包的原因应是拥塞.比如某一路由器进口速率高,出口低,而buffer不够大,有data burst的时候,会大量丢包. 发送方TCP收不到ACK, 启动拥塞控制, 停发,延迟, 再启动发送.

如果是TCP传送的话,第一张图显示发送方的速率平稳,应当是发送窗口已到最大,而网络带宽尚有富余;第二张图显示TCP反复处在slow start阶段, 发送速率由0开始指数增加,然后出现大量丢包, 于是发送速度回0,延迟,再slow star,...

有一点不解, 第二张图里全是这样一个一个的尖峰吗? 有没有最后平稳在一个比较低的水平? 如果一直是这样的锯齿,很象是发送方TCP有问题,一个参数ssthresh没有正确调整.

关于TCP拥塞控制, 可以参考一下http://www.faqs.org/rfcs/rfc2581.html.

这些是根据标准TCP来判断的, 不知道是不是符合实际的情况. 希望没有浪费老萨的时间.

家园 闹了半天是澳州啊,我还当是米国呢

澳洲这方面可能比较落后,效率也低。

家园 至少Sky-X工作很好

颇受上面喜欢

家园 继续不灵ing?
全看树展主题 · 分页首页 上页
/ 11
下页 末页


有趣有益,互惠互利;开阔视野,博采众长。
虚拟的网络,真实的人。天南地北客,相逢皆朋友

Copyright © cchere 西西河