fttb裝好了, 可是問題來了

[mis_waiszli]

報告樓主
若您是要下載滿載時來使用Tracert 跟 Ping的這個指令
依小弟目前的了解
若您下載(Port 80)滿載 Ping 跟 Tracert 的QOS本來就比較低
HTTP的QOS本來就會比ICMP還來的高
就像億聯的客服的比喻
家裡這條水管就這麼大
汽水要過 果汁要過 咖啡也要過
假設汽水已經把這條水管塞滿了
其他的飲料要過的話當然只能等空檔囉
若是因為這個原因，我想真的不是中華的問題
所以會暴Ping或是Ping質很高小弟都覺得是正常滴
如果您以不抓檔案為前提使用Ping及Tracert 這二個數據
給小弟參考看看吧~
如果您要測試滴話等我一下嘿，我去抓再Po給您看
測好了給您參考

[030278032]

非常感謝
因為小弟在台北的哪一位朋友也是在下載當中ping168.95.1.1
回應品質也只有28ms , 而他的設備也跟小弟相同
不至於爆到180ms , 所以小弟才斗膽請你測試一下

期待你的圖 感謝

[valsilychen]

作者: 030278032

非常感謝
因為小弟在台北的哪一位朋友也是在下載當中ping168.95.1.1
回應品質也只有28ms , 而他的設備也跟小弟相同
不至於爆到180ms , 所以小弟才斗膽請你測試一下

期待你的圖 感謝

小弟也覺得前一位朋友說的有些道理。
敝公司使用的FTTB 1M/1M 固16IP(13可用)的方案，平時連線下載(非P2P)的速度也非常快，連線回美國總公司的ftp下載檔案通常的有 11x kB/s 穩定的速度。但是通常只要有一位同事全速下載資料，其他同事就會覺得慢。 tracert得到的數字都如您的例子，慘不忍睹。
有時客戶用NetTransport或FlashGet這類的工具，開啟多線下載台灣辦公室這裡的檔案，上傳瞬間滿載後，我們連外就會出現類似斷網的狀態。

慢的原因我覺得很簡單，只是塞車而已。一個單純的下載應用，把你可用的頻寬搾光了。您有沒有試過，在測試 tracert 168.95.1.1 時，利用限速工具將背景的測試下載的速度稍稍降低些？

以我們公司的狀況，只要獨佔頻寬的應用稍稍受到限制，tracert或ping的response time會獲得很大的改善。

若您的狀況如小弟所說，那您需要的是一部支援 QoS 的路由器，稍稍調整一下優先權，使用體驗會完全不同。

HTH