主题：【求助】不灵了，请弟兄们帮忙 -- 萨苏
家园 依然在这个问题上苦苦挣扎 这些天从Interface的duplex设定到Sky-X的Linktest进行的测试已经不下一百个了，问题依然如雾中看花。不过基本可以限定在网络的速度不平衡上，子矜等几位朋友的看法颇有道理。这个我最初是不大以为然的，因为网络方面双方的协议里有SLA,不应该有不平衡的问题，测试的时候带宽也的确达到要求，所以发现不平衡后一直在设备上找原因，现在看来。。。还难说，Vendor在作测试。问题很可能是Packet Loss导致的，确认中。
家园 我的猜测 从这个“症状”链接出处来看，问题很可能是在Office2(Server）端，而与网络无关。
“（Office2的）ACK MSG，里面的Window Size却在不断变化，从16K到0.3K”就会造成“从Office1向Office2传递的时候，（Throughput）为间断的波峰”。这里需要解释一下TCP Packet里的Window Size代表的是“receive window”，其目的是用于flow control。TCP协议中还有一种window是congestion window，用于congestion control。TCP sender在传送数据时，取两个window的最小值。receive window波动的原因一般和网络（congestion，packet loss）无关，而是由于receiver端的application process consume receive buffer的速度不够快。Packet loss或timeout会造成congestion window的波动，但当receive window只有0.3K的时候，throughput太低的原因基本上可以肯定是receiver端的问题。
我的建议是按以下顺序调查Office2上的：
1、application：这个可能性最大。application如果写的不好的话，无法处理大流量的数据，就会造成这种问题。可以试试在office2上用ftp从office1下载一个大文件，看看是不是还有throughput波动的情况。
2、operating system：这个可能性很小。win2000的tcp/ip协议栈的performance还是不错的，处理20M的流量应该没问题。可以试一试重装一个干净的系统，关掉其他所有不必要的service和application。
3、网卡：实在没办法了就换个网卡试试。
- 复 我的猜测
家园 骆驼兄的推断也是我现在寄予希望的地方 刚刚让工程师下去在Osaka Server的门口装一个Sniffer，看看结果如何，希望柳暗花明。
- 复 我的猜测
家园 俺也发急，出个馊点子 老萨已经测试过无数次物理链路了。
1.假设如果物理线路没有问题，问题就在两台服务器上了。
建议：
两个办公室用两台普通工作站替代主机传送数据
前提是：两台工作站性能良好，经过了简单的网络传输测试
1.1如果测试结果表明传输速率正常，那么用替换的方式检测两台主机，找出哪一台主机有问题？
1.2传输速率还不正常
可能ISP的线路有问题,请设法检测路由器端口到ISP之间的线路啦,这个好像有点悬。
家园 还在较劲中 现在看来问题已经锁定在悉尼到墨尔本段的网络上，这一段我们是买的带宽，本来认为不应该有问题的。。。
这些天都在和它折腾呢。
- 复 还在较劲中
家园 闹了半天是澳州啊，我还当是米国呢 澳洲这方面可能比较落后，效率也低。
家园 对Sky-X测试中 Linktest的Packet size设置为Rondam，结果经常有Packet Loss,当时认为是中间网络的问题，现在看来，可能只是测试方法问题，怪我们对于这个设备不掌握。
我们在Sky-X中设置路由的时候规定了专用的MTU尺寸，但不知道是否会产生效果，很怀疑设置了MTU,是否它按照设置工作。
此外，似乎这东西还能测FTP，方法就不太理解了，两个命令ftpsource和ftprecv,侯教。
家园 好长时间了，难题还没解决啊？ 近来很少见到萨兄的文章了，估计时间都花在攻关赏了吧？
家园 Sky-X死拉死拉地！ 想研究其内部的东西简直要人命阿。。。
家园 个人一点拙见 我一直在关注这个帖子,正如几位大虾所说的，我也认为多半是TCP协议的差错控制或拥塞控制机制在跨越多传输链路路经时造成的问题。我不熟悉SKY-X加速器的工作原理，上网查了查没有详细说明，不过既然说是针对高延时卫星链路起到加速作用，想来应该是类似增加滑动窗口的大小，使用大量硬件缓冲自动控制重传。如果发生频繁的重传肯定会是这样。我个人觉得萨兄这个方案大概要推翻了。
家园 至少Sky-X工作很好 颇受上面喜欢