【問題】有關於光世代會掉ping??

如題, 最近申請了光世代, 發現有一個問題存在..
當我在玩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

奇怪 您的PING值似乎也很不穩定,當是否有在傳輸資料?

[QUOTE=cheerx;1016606]奇怪 您的PING值似乎也很不穩定,當是否有在傳輸資料?[/QUOTE]

我是在傳資料阿, 我開頭就說了, 我上傳開滿檔時ping HiNet DNS會掉ping
..

滿檔, 頻寬用完了, 會有 pocket loss 是很正常的...

[QUOTE=ismile;1016622]滿檔, 頻寬用完了, 會有 pocket loss 是很正常的...[/QUOTE]
這應該不太對吧... 有人可以試試看是否有此行情情況嗎? 我在別的網站看過應該是不會有此情況發生的.

上傳滿檔PING會pocket loss 是蠻正常的,我也是如此
除非是有額外的上傳頻寬

[QUOTE=billhi;1016638]上傳滿檔PING會pocket loss 是蠻正常的,我也是如此
除非是有額外的上傳頻寬[/QUOTE]

[COLOR="Red"]除非是有額外的上傳頻寬[/COLOR]

這樣就不算是滿載上傳,pocket loss這是正常現象 :)

用cable試了一下,上傳滿檔並不會掉...
只有反應時間會偏高
Ping statistics for 168.95.192.1
Packets: Sent = 116, Received = 116, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 28ms, Maximum = 83ms, Average = 51ms
Control-C

如果沒有頻寬管理的話，上傳滿檔就一定會掉ping，下載滿檔也會。

很正常！
上傳滿檔，開網頁都會頓掉了。
PING值不只會掉還會逾時~

問題是會Request timed out很嚴重..
我詢問過同樣使用光世代的人他說他不會有此問題發生耶...

有使用光世代的朋友可以試試看嗎? 拜託各位了..

上傳不要全吃滿就好了, 95% 限起來就不會 ping 飆高或 timeout 了

Hinet FTTB 10M/2M

下載滿檔Ping 168.95.192.1 不會掉封包 最低13ms 最高180ms~185ms
上傳滿檔Ping 168.95.192.1 一樣不會掉封包最低 13ms 最高 25ms

一切穩定正常～測試5次，都差不多是這個值範圍內！

有時候剛好那個時段是線路節點Router的問題
把tracert 168.95.192.1的結果post出來看看吧

以下我的資訊一切正常，僅供參考 05/11 11:04 PM 分測試的！

C:\>tracert 168.95.192.1

Tracing route to hntp1.hinet.net [168.95.192.1]
over a maximum of 30 hops:

1 12 ms 12 ms 12 ms 61-216-116-254.dynamic.hinet.net [61.216.116.254
]
2 11 ms 11 ms 12 ms hc-c76r1.router.hinet.net [168.95.90.98]
3 12 ms 11 ms 14 ms hc-c12r1.router.hinet.net [211.22.38.82]
4 13 ms 27 ms 22 ms tp-crs11.router.hinet.net [220.128.1.130]
5 13 ms 13 ms 21 ms tp-s2-c6r10.router.hinet.net [220.128.1.137]
6 13 ms 20 ms 13 ms 210.59.204.198
7 15 ms 15 ms 15 ms hntp1.hinet.net [168.95.192.1]

Trace complete.

ping 的 timeout 設多一點就不會掉ping了

example : ping -w 5000 192.168.1.1

[QUOTE=starhw;1016655]問題是會Request timed out很嚴重..
我詢問過同樣使用光世代的人他說他不會有此問題發生耶...

有使用光世代的朋友可以試試看嗎? 拜託各位了..[/QUOTE]

有問題就報修嘛!

0800-080-128

每個人的測試環境很難一樣的，下載滿檔和上傳滿檔也要看怎麼測的！

有時是瞬間連線數過大所造成的問題，說上下傳滿檔也是不太完全的說法。

若是單檔單點的上下載滿檔要說掉PING當然可能性就不大，但你是用bt，再加

上你的上傳又不設限，水管大，當然就會有連線數瞬間暴量的可能性。

[QUOTE=rogershu;1016691]有問題就報修嘛!

0800-080-128

每個人的測試環境很難一樣的，下載滿檔和上傳滿檔也要看怎麼測的！

有時是瞬間連線數過大所造成的問題，說上下傳滿檔也是不太完全的說法。

若是單檔單點的上下載滿檔要說掉PING當然可能性就不大，但你是用bt，再加

上你的上傳又不設限，水管大，當然就會有連線數瞬間暴量的可能性。[/QUOTE]

我連使用HiNet 測試FTP 單線上傳測試都會掉封包我上來問問大家, 因為我不止一台電腦我連單台測試都會這樣... 所以才想是否有人可以幫我測試看看.

我的認知裡面也是不管上下載頻寬
當你用滿的時候ping就會loss了
水管已經塞滿了
你的icmp封包在一定的時間出不去回不來
顯示time out是正常的
要是網路有問題
你限制一點頻寬下來給ping用就不應該會好
剛有位朋友提供time out時間的調整方式
就是多一些時間讓你的封包去擠水管

[B]丠[/B]夶爺, 尛弟被您考倒了

[QUOTE=starhw;1016604]如題, 最近申請了光世代, 發現有一個問題存在..
當我在玩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[/QUOTE]

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

[QUOTE=FYI;1016826][B]丠[/B]夶爺, 尛弟被您考倒了[/QUOTE]

您比較厲害啦
:lovely:

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

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

[url]http://winmtr.sourceforge.net/[/url]

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

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

[url]http://winmtr.sourceforge.net/[/url][/QUOTE]
|------------------------------------------------------------------------------------------|
| 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 的狀態，建議看看下面這一篇

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

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

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

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