gpowdera
2001-05-09, 05:37 PM
我每次在上傳時一邊下載
好像下載的速度掉很多
本來20k
掉到5k
各位也有這種情形嗎
順變問一下
網路卡跟跟速度有關嗎
贊助商連結
好像下載的速度掉很多
本來20k
掉到5k
各位也有這種情形嗎
順變問一下
網路卡跟跟速度有關嗎
贊助商連結
|
贊助商連結 頁 :
[1]
2
gpowdera 2001-05-09, 05:37 PM 我每次在上傳時一邊下載 好像下載的速度掉很多 本來20k 掉到5k 各位也有這種情形嗎 順變問一下 網路卡跟跟速度有關嗎 贊助商連結 StrifeDu 2001-05-09, 06:22 PM 會使download變慢！ 網卡的話、現在都是10/100M、應該都會取100M、 所以應該沒差！ sami 2001-05-09, 07:45 PM 原始作者是 : gpowdera 我每次在上傳時一邊下載 好像下載的速度掉很多 本來20k 掉到5k 各位也有這種情形嗎 順變問一下 網路卡跟跟速度有關嗎 建議您看清楚什麼叫做"A"DSL 非同步模式傳輸下 本來上傳就會影響下載 要足的頻寬 請租用專線 or 用 雙向Cable gpowdera 2001-05-10, 06:39 PM 原始作者是 : sami 原始作者是 : gpowdera 我每次在上傳時一邊下載 好像下載的速度掉很多 本來20k 掉到5k 各位也有這種情形嗎 順變問一下 網路卡跟跟速度有關嗎 建議您看清楚什麼叫做"A"DSL 非同步模式傳輸下 本來上傳就會影響下載 要足的頻寬 請租用專線 or 用 雙向Cable 如果可以申請雙向cable的話 我早就申請了 專線...... 別妄想了 rs125 2001-05-11, 09:51 AM 沒錯... 一定會變慢... 像我們公司就是一個好例子... 只要一有人在寄檔案稍大的mail... 包準"ㄍㄧㄢ"(四聲)四起... 呵呵...這也是ADSL的缺點... shyong 2001-05-11, 10:32 AM 如果對於 TCP/IP 有所瞭解者皆知 , 這是當然的 !! 以下我就提出證明 : 假設我現在 Upload Data to http://home.kimo.com.tw/xxxxxx 這時候 DU Meter 測得上傳速率為 AVG : 50 Kbit 然而 ADSL 512/64 的架構當中 , DSLAM 鎖住了線路頻寬 也就是你由 ATU-R 傳送出去的 DATA 流量需小於等於 64 Kbit 而考量到 TCP/IP 架構問題 , 一個框架當中, 有一個開始位元 與一個結束位元 , 如果以一串 8 bit 的 Data 而言 , 實際傳送 有效資料為 6 bit 所以 , 64 Kbit ---> 實體線路頻寬 51 Kbit ---> 經由 TCP/IP 的 傳輸層(Transport Layer) 的分割成封包(Packet)之後 由此得知 , 你可上傳最大極限為 51 Kbit 但是為什麼在上傳 Data to home.kiom.com.tw 時,此刻進行 瀏覽網頁(事實上就是在進行下載)會嚴重 Dealy 呢 ? 這是因為當你再下載資料(data)時 , 同時也會上傳資料 你可以做個實驗,將 DU Meter 開啟 , 然後再開啟 Broswer 瀏覽 此時你認為應當只有下傳資料啊!!為什麼 DU Meter 也出現了 上傳資料的長條圖形 , 這個原理很簡單 , 因為當你進行 Download Data 時 , 你的 PC 還是會傳送資料到 Server 端 例如: 下載速率為 400 Kbit 時 , 會上傳約 5.6 kbit 這就證明上傳時為什麼下載會嚴重 Dealy 因為你已將上傳的頻寬佔滿了, 導致下載時所需要的上傳資料的 頻寬無法使用或壅塞 , 因此會嚴重 Dealy ~~~ ##########上述言論如有誤請糾正########## gpowdera 2001-05-12, 03:45 PM 原來如此啊 shyong兄 你真是學識淵博 請問你是用adsl 還是cable JOHNNIE 2001-05-12, 04:08 PM 嗯！ 的確… 一般我們TCP/IP 網路通訊協定都是使用多交握式的方式來傳輸資料！(希望沒有用錯說法) 也就是如樓上的shyong版主所說的… 有下載就要有上傳…以來check資料！ 相對的，上傳也需要下載check(其實就是一傳一送互相對調罷了) 可是偏偏ADSL的上傳又是超級的!@#$@$ 所以當我們一上傳資料時，在下載方面所需要的上傳頻寬就被佔去… 導致下載遲遲無法獲得確認！此時資料就會low下來等待… 唉… 這是使用ADSL的悲哀… 真希望『真正寬頻』能快點來臨… PS2178 2001-05-12, 08:33 PM 原始作者是 : JOHNNIE 嗯！ 的確… 一般我們TCP/IP 網路通訊協定都是使用多交握式的方式來傳輸資料！(希望沒有用錯說法) 也就是如樓上的shyong版主所說的… 有下載就要有上傳…以來check資料！ 相對的，上傳也需要下載check(其實就是一傳一送互相對調罷了) 可是偏偏ADSL的上傳又是超級的!@#$@$ 所以當我們一上傳資料時，在下載方面所需要的上傳頻寬就被佔去… 導致下載遲遲無法獲得確認！此時資料就會low下來等待… 唉… 這是使用ADSL的悲哀… 真希望『真正寬頻』能快點來臨… ====================== 那麼 小弟有個 ideal 不知是否可行 1. Increase the sliding window size of TCP. 2. Decrease the sending buffer size. So, it is supposed won't occupy too many resource. 請各位仁兄惠與指教 Thanks! shyong 2001-05-12, 09:17 PM PS2178 所言的情形 ,正是我們長討論的 MTU 值 關於 Sliding Window 方面 , 修改之後似乎沒有什麼差別 至於減少送出的確認訊息 這方面屬於 ISO 中的 "資料鏈接層(Data Link Layer)" 有所規定 , 據瞭解是不能隨意改變的 ~~~~~~ 因為這是為了確認所 Send Packer 到目的端的可靠性所制定的 也就是我們所謂的 Checksum 建議不要嚐試去修改這部分 , 否則可能會導致資料嚴重錯誤 如果考慮要加快速度的話 , 可以考慮採用 UDP Protocol 這可以少去 CheckSum 的 time |
|
|