PTT數位生活區 / Broad_Band (寬頻網路)

Re: [ADSL] HINET 4M/128K LAG的問題

看板Broad_Band (寬頻網路)作者 (被罰跪主機板的)時間12年前 (2013/10/18 15:45), 編輯推噓3(3推 0噓 16→)
留言19則, 6人參與, 最新討論串2/2 (看更多)
跟朋友商借正常使用中的無線分享器及無線網卡來測試，但還是LAG 所以設備損壞可以排除。 沒想到電腦直接連數據機還是一樣LAG...... HINET一直說經過分享器的話頻寬可能會縮減，這是用戶設備的問題， 而我也一直信以為真，直到...... 使用HINET的測速工具Dr.speed測試的結果如下： http://ppt.cc/BK1Z http://ppt.cc/wip7 報給HINET永遠也只會跳針說他們測試的結果沒問題...... 請容我說一句"裝肖唯喔！" 還到這種情形該怎麼跟HINET反應比較好？ tracert及ping的結果如下所列： C:\Users\Yihong>tracert www.hinet.net 在上限 30 個躍點上 追蹤 www.hinet.net [202.39.224.7] 的路由: 1 333 ms 68 ms 53 ms h254.s98.ts.hinet.net [168.95.98.254] 2 84 ms 434 ms 887 ms 168.95.221.210 3 389 ms 839 ms 979 ms TNE1-3011.hinet.net [220.128.26.50] 4 295 ms 71 ms 67 ms TPDT-3011.hinet.net [220.128.3.2] 5 58 ms 62 ms 59 ms TPDB-3407.hinet.net [220.128.1.237] 6 1352 ms 1089 ms 909 ms 211.22.41.237 7 417 ms 764 ms 251 ms 202-39-224-7.HINET-IP.hinet.net [202.39.224.7] 追蹤完成。 C:\Users\Yihong>tracert 168.95.1.1 在上限 30 個躍點上 追蹤 dns.hinet.net [168.95.1.1] 的路由: 1 67 ms 49 ms 76 ms h254.s98.ts.hinet.net [168.95.98.254] 2 1565 ms 407 ms 305 ms 168.95.221.210 3 757 ms 1903 ms 1303 ms SKC1-3011.hinet.net [220.128.24.142] 4 1737 ms 1486 ms 572 ms r31-kh.hinet.net [220.128.24.117] 5 54 ms 55 ms 58 ms 61-219-3-65.HINET-IP.hinet.net [61.219.3.65] 6 809 ms 2127 ms * dns.hinet.net [168.95.1.1] 7 381 ms 754 ms 566 ms dns.hinet.net [168.95.1.1] 追蹤完成。 C:\Users\Yihong>ping 168.95.1.1 -t Ping 168.95.1.1 (使用 32 位元組的資料): 回覆自 168.95.1.1: 位元組=32 時間=230ms TTL=250 回覆自 168.95.1.1: 位元組=32 時間=1180ms TTL=250 回覆自 168.95.1.1: 位元組=32 時間=325ms TTL=250 回覆自 168.95.1.1: 位元組=32 時間=139ms TTL=250 回覆自 168.95.1.1: 位元組=32 時間=184ms TTL=250 回覆自 168.95.1.1: 位元組=32 時間=123ms TTL=250 回覆自 168.95.1.1: 位元組=32 時間=63ms TTL=250 回覆自 168.95.1.1: 位元組=32 時間=1267ms TTL=250 回覆自 168.95.1.1: 位元組=32 時間=1626ms TTL=250 回覆自 168.95.1.1: 位元組=32 時間=1997ms TTL=250 回覆自 168.95.1.1: 位元組=32 時間=330ms TTL=250 回覆自 168.95.1.1: 位元組=32 時間=290ms TTL=250 回覆自 168.95.1.1: 位元組=32 時間=780ms TTL=250 回覆自 168.95.1.1: 位元組=32 時間=92ms TTL=250 回覆自 168.95.1.1: 位元組=32 時間=97ms TTL=250 回覆自 168.95.1.1: 位元組=32 時間=79ms TTL=250 回覆自 168.95.1.1: 位元組=32 時間=79ms TTL=250 回覆自 168.95.1.1: 位元組=32 時間=328ms TTL=250 回覆自 168.95.1.1: 位元組=32 時間=1334ms TTL=250 回覆自 168.95.1.1: 位元組=32 時間=91ms TTL=250 回覆自 168.95.1.1: 位元組=32 時間=683ms TTL=250 回覆自 168.95.1.1: 位元組=32 時間=989ms TTL=250 回覆自 168.95.1.1: 位元組=32 時間=1671ms TTL=250 回覆自 168.95.1.1: 位元組=32 時間=449ms TTL=250 回覆自 168.95.1.1: 位元組=32 時間=94ms TTL=250 回覆自 168.95.1.1: 位元組=32 時間=97ms TTL=250 回覆自 168.95.1.1: 位元組=32 時間=65ms TTL=250 回覆自 168.95.1.1: 位元組=32 時間=937ms TTL=250 回覆自 168.95.1.1: 位元組=32 時間=268ms TTL=250 回覆自 168.95.1.1: 位元組=32 時間=59ms TTL=250 回覆自 168.95.1.1: 位元組=32 時間=962ms TTL=250 回覆自 168.95.1.1: 位元組=32 時間=100ms TTL=250 回覆自 168.95.1.1: 位元組=32 時間=1609ms TTL=250 回覆自 168.95.1.1: 位元組=32 時間=48ms TTL=250 回覆自 168.95.1.1: 位元組=32 時間=55ms TTL=250 回覆自 168.95.1.1: 位元組=32 時間=1275ms TTL=250 回覆自 168.95.1.1: 位元組=32 時間=1521ms TTL=250 回覆自 168.95.1.1: 位元組=32 時間=1119ms TTL=250 回覆自 168.95.1.1: 位元組=32 時間=1373ms TTL=250 回覆自 168.95.1.1: 位元組=32 時間=127ms TTL=250 168.95.1.1 的 Ping 統計資料: 封包: 已傳送 = 40，已收到 = 40, 已遺失 = 0 (0% 遺失)， 大約的來回時間 (毫秒): 最小值 = 48ms，最大值 = 1997ms，平均 = 603ms Control-Break 回覆自 168.95.1.1: 位元組=32 時間=60ms TTL=250 回覆自 168.95.1.1: 位元組=32 時間=60ms TTL=250 回覆自 168.95.1.1: 位元組=32 時間=547ms TTL=250 回覆自 168.95.1.1: 位元組=32 時間=372ms TTL=250 回覆自 168.95.1.1: 位元組=32 時間=186ms TTL=250 回覆自 168.95.1.1: 位元組=32 時間=109ms TTL=250 回覆自 168.95.1.1: 位元組=32 時間=920ms TTL=250 168.95.1.1 的 Ping 統計資料: 封包: 已傳送 = 47，已收到 = 47, 已遺失 = 0 (0% 遺失)， 大約的來回時間 (毫秒): 最小值 = 48ms，最大值 = 1997ms，平均 = 561ms Control-C ^C 有點長，感謝您耐心看完。 這種數值，真的不是HINET的問題嗎？ －－－－ LAG了一個多月，上星期終於忍不住報了故障，但HINET說他們測試的 結果沒問題，最後只來換了一台數據機，但沒有太大的改善。 使用HINET測速網頁測試的結果約為1.5M/89K，因為是使用無線分享器 上網，所以頻寬不足的部份我想爭議並不大，但是這跟反應速度似乎沒 有直接關係？(不曉得我的認知是否正確@@) 以下為tracert www.hinet.net及www.yahoo.com.tw的結果： C:\Users\Yihong>tracert www.hinet.net 在上限 30 個躍點上 追蹤 www.hinet.net [202.39.224.7] 的路由: 1 2 ms 1 ms 1 ms 192.168.0.1 2 133 ms 43 ms 42 ms h254.s98.ts.hinet.net [168.95.98.254] 3 126 ms 41 ms 44 ms 168.95.220.210 4 78 ms 352 ms 83 ms 220-128-26-54.HINET-IP.hinet.net [220.128.26.54] 5 271 ms 55 ms 295 ms TPDT-3011.hinet.net [220.128.3.2] 6 520 ms 487 ms 74 ms TPDB-3407.hinet.net [220.128.1.237] 7 303 ms 77 ms 135 ms 211.22.41.237 8 54 ms * 118 ms 202-39-224-7.HINET-IP.hinet.net [202.39.224.7] 追蹤完成。 C:\Users\Yihong>tracert www.yahoo.com.tw 在上限 30 個躍點上 追蹤 tw-rc.g01.yahoodns.net [119.160.242.96] 的路由: 1 2 ms 1 ms 1 ms 192.168.0.1 2 44 ms 261 ms 150 ms h254.s98.ts.hinet.net [168.95.98.254] 3 186 ms 42 ms 40 ms 168.95.221.210 4 84 ms 51 ms 254 ms SKC1-3011.hinet.net [220.128.24.142] 5 309 ms 246 ms 51 ms TPDT-3011.hinet.net [220.128.24.2] 6 51 ms 44 ms 160 ms TPDT-3301.hinet.net [220.128.3.137] 7 77 ms 54 ms 92 ms 211.22.41.45 8 54 ms 54 ms 59 ms te-8-1.bas1-1-prd.tw1.yahoo.com [119.160.240.1] 9 622 ms 221 ms 52 ms w2.rc.vip.tw1.yahoo.com [119.160.242.96] 追蹤完成。 今天tracert的結果算是好的，有時會從第2項開始全部都600ms以上。 電腦：WIN7 / 9850+ / 4G DDR2 800 / Atheros AR5007UG Wireless Network Adapter 無線分享器：TP-LINK TL841N 無線網卡的流量流計：http://ppt.cc/V1iV CODOMO的連線監控：http://ppt.cc/kC6a 想請問若真如HINET所說的"測試正常"，那麼問題可能出在我電腦上的什麼地方呢？ 又或者說......是HINET的問題？ 補充一下： 報修前LAG時段都在深夜11點左右開始，這時看PTT按鍵會有1秒以內的延遲，大約 1:30~2:00會"極度"LAG，要2~4秒才有反應，到了早上6點~8點(不定)就自動好了。 報修後(換過數據機後)LAG時段變成早上，反而晚上6點~7點後就順了。 -- ※ 發信站: 批踢踢實業坊(ptt.cc) ◆ From: 1.172.113.138
→
10/18 15:58, , 1F
你LAG的時候數據機燈會不會狂閃?
10/18 15:58, 1F
不會耶。 COMODO的連線監控跟NETLIMITER也沒發現異常上/下載的東西。 ※ 編輯: neorange 來自: 218.164.85.252 (10/18 16:04) 4點一過突然又順了 C:\Users\Yihong>ping 168.95.1.1 Ping 168.95.1.1 (使用 32 位元組的資料): 回覆自 168.95.1.1: 位元組=32 時間=36ms TTL=249 回覆自 168.95.1.1: 位元組=32 時間=34ms TTL=249 回覆自 168.95.1.1: 位元組=32 時間=34ms TTL=249 回覆自 168.95.1.1: 位元組=32 時間=35ms TTL=249 168.95.1.1 的 Ping 統計資料: 封包: 已傳送 = 4，已收到 = 4, 已遺失 = 0 (0% 遺失)， 大約的來回時間 (毫秒): 最小值 = 34ms，最大值 = 36ms，平均 = 34ms 很難不讓人懷疑HINET是不是又在搞什麼時段性限縮的東西..囧 ※ 編輯: neorange 來自: 218.164.85.252 (10/18 16:09)
推
10/18 16:13, , 2F
回報你的人應該是查ADSL的師傅 單子應該沒有到機房去
10/18 16:13, 2F
那這個部份要怎麼跟客服溝通？ 我是打數據機上的客服電話去回報的。 順帶一題，DR.Speed測試結果沒有跟著網路順了有所起色：http://ppt.cc/Bkwq ※ 編輯: neorange 來自: 218.164.85.252 (10/18 16:18)
→
10/18 16:17, , 3F
報修時註明LAG時間 請機房監控一下你線路的流量
10/18 16:17, 3F
有耶，本來都深夜時段LAG，上次報修後變早上LAG。 ※ 編輯: neorange 來自: 218.164.85.252 (10/18 16:19)
推
10/18 16:31, , 4F
把收集的資料上傳至該網頁 http://goo.gl/ysCwGi
10/18 16:31, 4F
→
10/18 16:33, , 5F
不過周末好像沒人上班 最快也要周一才會有回覆吧!?
10/18 16:33, 5F
OK，多謝提供這個資訊。
推
10/18 17:04, , 6F
再次報修，請查修帶NB接數據機測速給您看
10/18 17:04, 6F
嗯嗯，上次來我沒注意到這部份，這次我會請他測測看。
→
10/18 19:50, , 7F
如果原PO已經由Dr.Speed程式來測試速率過的話，那麼理論上
10/18 19:50, 7F
→
10/18 19:51, , 8F
應該是有測速後的數據結果可提供給查修單位了解才對....如
10/18 19:51, 8F
→
10/18 19:54, , 9F
果原PO的測速方式是以單一電腦接線後撥號測試的話，那建議
10/18 19:54, 9F
→
10/18 19:55, , 10F
還是要反映給查修單位處理才是，另外也可依照樓上f大所說方
10/18 19:55, 10F
→
10/18 19:56, , 11F
式請人員當下測速就可知到底是否有其問題需要解決了
10/18 19:56, 11F
PO這篇文的時候是以單一電腦接線後撥號喔。 附上的Dr. Speed截圖跟tracert/ping的資料也都是在此狀態下測得的結果。
→
10/18 20:00, , 12F
為什麼不能直接插在小烏龜測速度呢?
10/18 20:00, 12F
→
10/18 20:00, , 13F
測出來有問題 很明顯就中華的問題囉
10/18 20:00, 13F
因為這台電腦是桌機，要搬動有點麻煩。(其實是我懶XD) 不過實在LAG到受不了，所以今天就搬下樓直接接數據機測了。 －－ 當時大概是15點左右，接上數據機後撥號上網號還是很LAG，神奇的是16點整點 一到突然就好了，ping值穩定的在30幾~40幾之間，現在又把電腦搬回樓上用無 線，目前用是很順。 做一下整理好了： 一開始申請的是2M/64K，後來有搭到免費升4M/128K的車，現在回想一下，LAG的情 況似乎是從這個時候開始。 起初是家人深夜使用時會LAG，但我白天使用時不會。 ↓ 報修，HINET來換了一台數據機。 ↓ 家人表示深夜使用時順了，但變成我白天使用時LAG。 ※ 編輯: neorange 來自: 218.164.80.239 (10/18 20:34)
→
10/21 11:14, , 14F
如果trace route第一個節點的回應值就有嚴重延遲，其實通
10/21 11:14, 14F
→
10/21 11:14, , 15F
常會比較傾向於判斷是內部網路壅塞或電腦問題，而且原PO
10/21 11:14, 15F
→
10/21 11:15, , 16F
ping HiNet DNS 也會動輒延遲到 1000 ms上下，如果這是以
10/21 11:15, 16F
→
10/21 11:15, , 17F
只有單台電腦連接數據機撥號上網」測速下所得的結果，會
10/21 11:15, 17F
→
10/21 11:15, , 18F
較建議請查修人員帶一台有乾淨作業系統的NB去現場測試比
10/21 11:15, 18F
→
10/21 11:15, , 19F
對看看
10/21 11:15, 19F
sigurose大的建議跟我想的一樣，下次我會請查修人員帶乾淨的NB來測測看。 其實我也有想過是不是自己電腦中了什麼東西，所以重灌過一次，不過沒有改善， 後來裝了CODOMO的防火牆跟NetLimiter來監控連線，但LAG發生時沒有發現異常。 上個星期六、日(19、20)整天都非常順暢，但測得的下載速率依然只有1.5M上下， 一直到21號凌晨2點又開始大LAG，ping平均值在1000以上，早上7點整後ping平均 值突然下降至100。 這段時間我在電腦上的動作只有大約每10分鐘PING一次，軟體方面除了小紅傘跟 COMODO，其他東西全都關掉。 現在是覺得大LAG都是整點開始、整點結束這點很謎呀。 我是想說先請HINET把該有4M的下載速率弄好後再來觀察看看LAG情形有沒有改善。 ※ 編輯: neorange 來自: 218.164.80.239 (10/21 23:05)
‣ 更多 neorange 的文章
文章代碼(AID): #1IOESom4 (Broad_Band)
Broad_Band 近期熱門文章
更多 近期熱門文章 >>
PTT數位生活區 即時熱門文章
更多 即時熱門文章 >>
‣ 更多 neorange 的文章
文章代碼(AID): #1IOESom4 (Broad_Band)