有人使用光世代上傳時會掉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

另外我連使用FTP上傳資料至HiNet測試FTP 也會Request timed out.. 只是沒有BT來得嚴重.

可否請好心人幫忙測試一下.

掉就掉吧, 只要不掉封包就好.

　　有一個問題…掉ping跟掉封包有什麼不同？

　　ping的原理不就是丟一個封包出去請對方伺服機丟一個封包回來嗎？
如果ping會掉不就代表封包會掉嗎？會掉封包資料不完整時就會多花好幾個封包來重新確認該封包的資料。

　　那不知有那位達人可以解釋掉ping不同等掉封包？

　　尤其是online game或是webcam的應用時...

附的PING資訊 是開BT時的??
PING值看起來很正常啊...才2位數
只是不怎麼穩定@@
還有 PING其它網站也是如此嗎?

掉ping不見得等於掉封包. 為什麼呢?

ping只是一種ICMP message type, echo request 與 echo reply 的結果.

除了測試網路有沒有通, 並沒有什麼真正的價值.

所以ICMP與其他真正的service (Http, ftp, snmp...etc) 在網路端不見得被相同的對待.

當網路流量繁重的時候, 管理者可以設定優先處理真正有用的訊務而忽略/放低ICMP的請求

讓真正的服務順暢但是ping的封包最後處理,甚至掉包都不care.

上傳滿檔,代表ISP對你承諾的Qos只能給你這麼多, 舉例說上傳2Mbps好了, p2p跑滿時,

若沒有空間再安插ping的服務封包進去時, 自然就是drop ping packet.


另外, 多數應用程式在網路層與應用層都有自我修復的機制, 可讓遺失的封包重傳, 重組成

完整有用的資料, 像是TCP based 的流量都有這種能力, 達成"過程可能有掉包 但是實際上

最後資料是完整/無掉包"的結果

但是ping沒有這樣的能力, 掉一個就是一個, 每次單獨的Ping若失敗都不會重傳.

所以一般人才會以多次Ping, 連續ping的方式, 觀察多次檢視連線回應的狀態.


當然, 硬要說掉ping也是一種掉封包也沒錯, 不過, 這就很文字化誰都知道而完全與技術無關了.