如題, 最近申請了光世代, 發現有一個問題存在..
當我在玩BT時,只要我上傳滿檔不限速的話會有掉ping的問題存在, 請問這是正常的嗎??
Pinging 168.95.192.1 with 32 bytes of data:

Reply from 168.95.192.1: bytes=32 time=25ms TTL=247
Reply from 168.95.192.1: bytes=32 time=19ms TTL=247
Reply from 168.95.192.1: bytes=32 time=14ms TTL=247
Reply from 168.95.192.1: bytes=32 time=14ms TTL=247
Reply from 168.95.192.1: bytes=32 time=68ms TTL=247
Reply from 168.95.192.1: bytes=32 time=14ms TTL=247
Reply from 168.95.192.1: bytes=32 time=50ms TTL=247
Request timed out.
Request timed out.
Request timed out.
Reply from 168.95.192.1: bytes=32 time=16ms TTL=247
Reply from 168.95.192.1: bytes=32 time=15ms TTL=247
Reply from 168.95.192.1: bytes=32 time=15ms TTL=247
Reply from 168.95.192.1: bytes=32 time=20ms TTL=247
Reply from 168.95.192.1: bytes=32 time=48ms TTL=247
Reply from 168.95.192.1: bytes=32 time=19ms TTL=247
Reply from 168.95.192.1: bytes=32 time=14ms TTL=247
Reply from 168.95.192.1: bytes=32 time=14ms TTL=247
Request timed out.
Reply from 168.95.192.1: bytes=32 time=50ms TTL=247
Reply from 168.95.192.1: bytes=32 time=26ms TTL=247
Reply from 168.95.192.1: bytes=32 time=25ms TTL=247
Reply from 168.95.192.1: bytes=32 time=14ms TTL=247
Request timed out.

Ping statistics for 168.95.192.1:
Packets: Sent = 24, Received = 19, Lost = 5 (20% loss),
Approximate round trip times in milli-seconds:
Minimum = 14ms, Maximum = 68ms, Average = 25ms
Control-C

好像不是只有FTTB這樣,我們的固定制ADSL有一部份最近也有這類問題 ,因為是多條線路,懷疑是介接網路頻寬不足,不過無法查證,只能報修再報修

丠夶爺, 尛弟被您考倒了

您比較厲害啦
:lovely:

試試看到這個網頁下載 WinMTR ，此程式可以測試出封包在哪一個節點上出現 loss 狀況。提供參考看看，PO 上你的測試，也許推測起來會比較準確。

我先前遇到的是在大陸，那就一點辦法都沒有了。

http://winmtr.sourceforge.net/

試試看到這個網頁下載 WinMTR ，此程式可以測試出封包在哪一個節點上出現 loss 狀況。提供參考看看，PO 上你的測試，也許推測起來會比較準確。

我先前遇到的是在大陸，那就一點辦法都沒有了。

http://winmtr.sourceforge.net/
|------------------------------------------------------------------------------------------|
| WinMTR statistics |
| Host - % | Sent | Recv | Best | Avrg | Wrst | Last |
|------------------------------------------------|------|------|------|------|------|------|
| 192.168.1.1 - 0 | 70 | 70 | 0 | 1 | 16 | 0 |
| 59-121-208-254.dynamic.hinet.net - 3 | 70 | 67 | 15 | 30 | 63 | 31 |
| tp-gs-c6r2.router.hinet.net - 3 | 69 | 67 | 0 | 31 | 156 | 47 |
| tp-gs-c12r1.router.hinet.net - 15 | 69 | 59 | 15 | 34 | 141 | 63 |
| tp-crs11.router.hinet.net - 5 | 69 | 65 | 15 | 30 | 78 | 62 |
| tp-s2-c6r9.router.hinet.net - 12 | 69 | 60 | 15 | 34 | 79 | 47 |
| tp-s2-c6r10.router.hinet.net - 14 | 69 | 60 | 15 | 27 | 63 | 16 |
| dns.hinet.net - 11 | 69 | 62 | 0 | 27 | 63 | 16 |
|________________________________________________|______|______|______|______|______|______|

這樣也看不出問題吧...

比對以下三種狀態
a. BT 上傳不設限
b. BT 關閉
c. BT 上傳設限

如果你真的很介意 PING 的狀態，建議看看下面這一篇

http://www.pczone.com.tw/vbb3/archive/t-118962.html
其中提到
而且現在有些ISP會故意把ICMP封包(如ping或traceroute封包)的優先權提升,
讓ping看來低些, 實用上卻沒有比較快.....

假設你的 PING 封包並沒有如上述的優先狀態，也就是說，PING 封包必須和你同時所傳送的BT封包排隊等待傳送，如果等待的時間超過PING程式所設定的等待封包時間就會出現 Request time out。

請仔細觀察這支程式的封包 Send 和 Recv 之間的差距，某些時候，你會看到 loss 的百分比先上升，之後再下降，這表示 先前被延遲的封包終於送到了:confused:

目前我也遇到這樣的問題，是否有解法?