【投票】下載30Mbps共享, 但是不保證頻寬?

[wind]

見到CM已經有開始進步
真的很讚，畢竟良性競爭是好事情

恕小弟問一個問題
TP是什麼東西，用處在於?缺點是什麼?
ISP使用TP的壞處是什麼呢?

[jufylee]

不影響一般上網遊戲等小量的網上用戶..倒是可以分享

因為長時間大量的下載用戶..有時真的會托慢速度耶!

[ACOPPER]

我認為當然應該開放，實行若有問題在想辦法解決，總體來說應該利大於弊（對用戶來說）。

[testaho]

雖然小弟不是東森用戶 不過讓小弟說一點小弟的看法
綜觀台灣大部分的P2P用戶
用的P2P軟體幾乎離不開EMULE或是BT,KURO,WINMX等這幾樣P2P發布軟體
因為小弟發覺到P2P還要考慮發布的問題存在
如果不是很流行一點的P2P軟體 始終就是不是那麼多人用
相對的對網路效率傷害就比較輕一點
台灣這邊使用的P2P發布軟體始終都是那幾樣

小弟提出一個構想
如果說上邊可以偵測常用的應用程式中P2P軟體的封包的話
導入到另一個路徑在網內另做處理(上下頻寬另計 就不加入共享頻寬之內)
上邊網管可以視情形在尖峰跟離峰時段做用戶P2P頻寬的動態調整
技術面上就是不知是否可行否?

(小弟認為基本上一般互動式應用跟所謂的P2P應用上
基本上使用上就有點區隔)

[normanfan]

我使用cable modem 玩p2p的感覺,
上傳頻寬是速率決定步驟..很容易就會拖慢下載速度.
上傳頻寬不夠,就算下載頻寬再怎麼大都是枉然的...

[raytracy]

最初由 testaho 發表
小弟提出一個構想
如果說上邊可以偵測常用的應用程式中P2P軟體的封包的話
導入到另一個路徑在網內另做處理(上下頻寬另計 就不加入共享頻寬之內)

或許也有很多網友和您一樣, 誤以為共享頻寬的瓶頸, 是在機房內; 其實不是.

共享頻寬指的是在用戶電路(Last mile, local loop)上的資源分享, 就像是 ADSL 的集縮, 雖然執行集縮的設備放在機房內, 但其實控管的是實體電路的集縮, 並不是機房內的集縮.

由於實體電路只有一條, 所以也沒有如您想像的「另一個路徑」可以走, 雖然我們可以在同一條電路內分割出不同應用的頻寬, 但不論 P2P 或其他應用, 都必須先一起走完實體電路, 才能進機房進行分流. 所以實體電路所能承載的總流量就會是一個瓶頸. 小弟先前提出的「QoS 管理」就是在試圖解決實體電路雍塞的問題. 「不限頻寬」概念則是要充分利用實體電路在離峰時間所剩餘的資源.

[testaho]

最初由 raytracy 發表

由於實體電路只有一條, 所以也沒有如您想像的「另一個路徑」可以走, 雖然我們可以在同一條電路內分割出不同應用的頻寬, 但不論 P2P 或其他應用, 都必須先一起走完實體電路, 才能進機房進行分流. 所以實體電路所能承載的總流量就會是一個瓶頸. 小弟先前提出的「QoS 管理」就是在試圖解決實體電路雍塞的問題. 「不限頻寬」概念則是要充分利用實體電路在離峰時間所剩餘的資源.

小弟的想法可能有問題 荒謬之處請見諒

小弟想要說的是從走完外面的實體電路進來後
是否有辦法可以企圖在同一條電路中分割出不同應用的頻寬出來
把p2P的這些零碎封包分開出來 做不同的處理 如此而已

「QoS 管理」「不限頻寬」達到充分利用離峰時段頻寬的概念
也是很好的想法
小弟也是期待您的想法有個好的結果出來..

[raytracy]

最初由 testaho 發表
小弟想要說的是從走完外面的實體電路進來後
是否有辦法可以企圖在同一條電路中分割出不同應用的頻寬出來
把p2P的這些零碎封包分開出來 做不同的處理 如此而已

會需要分開的緣由, 是因為遇到頻寬阻塞, 所以要讓互動應用先走; 不過, 在機房裡面, 甚至到連外頻寬以外, 在小弟這邊, 都沒有遇到頻寬阻塞, 因此不需要特別去分流.

就有點像是: 我在機房內有20線道的高速公路, 但卻只有 8 輛車要跑, 因此每輛車都可以自己占用一個車道全速前進, 不需要分流; 若此時還刻意去分流, 就好像硬把 8 輛車排在同一個車道內前進, 反而空了 19 個線道都浪費掉....

但實體電路的狀況則不同, 他是只有一個線道, 卻有 8 輛車想同時跑, 所以就要排個優先順序出來, 讓比較不重要的車晚一點跑, 重要的車可以優先超車.....

用戶第一個遇到壅塞的地方是 最後一哩電路, 其次是連外頻寬電路, 最後才是機房內骨幹電路. 不過, 在小弟這邊聯外頻寬和機房骨幹都很充裕, 所以只有最後一哩需要實施分流. 其他業者的狀況可能不盡相同, 他們實施分流的控制點也會不同.

[Fabian C]

最初由 raytracy 發表
但實體電路的狀況則不同, 他是只有一個線道, 卻有 8 輛車想同時跑, 所以就要排個優先順序出來, 讓比較不重要的車晚一點跑, 重要的車可以優先超車.....

QoS可以設定優先權,

我比較好奇的是...
因上傳會影響到下載,所以P2P用互必須要自己對上傳/下載做限制,
才不致於影響到正常的網站瀏灠、收發Email。
甚至於抓檔案下載滿檔時,也一樣會影響到正常的網站瀏覽、收發Email。

如果使用了QoS,把P2P和下載檔案的傳輸優先權排在後面時,
會不會即使下載上傳滿載,也不會影響到正常的網站瀏灠、收發Email??

如果是這樣的話,就方便多了!
就不必瀏覽網頁、講網路電話時,還要調整抓檔/P2P軟體的上傳下載頻寬
(不過...30M要下載滿檔也有點難...)

[raytracy]

最初由 Fabian C 發表
如果使用了QoS,把P2P和下載檔案的傳輸優先權排在後面時,
會不會即使下載上傳滿載,也不會影響到正常的網站瀏灠、收發Email??

如果 QoS 機制夠完整的話, 是可以做到這樣的. 不過必須兩端都做 (機房端, 客戶端), 如果只有一邊做, 效果有限....