線上訂房服務-台灣趴趴狗聯合訂房中心
發文 回覆 瀏覽次數:6106
推到 Plurk!
推到 Facebook!

傳輸的一個很怪異的現象,有人知道為什麼嗎

缺席
avex
初階會員


發表:19
回覆:49
積分:43
註冊:2003-03-28

發送簡訊給我
#1 引用回覆 回覆 發表時間:2005-07-20 19:48:35 IP:218.170.xxx.xxx 未訂閱
小弟分別用Indy及Borland 附的TCP socket 元件作傳輸實驗,  實驗的目的在求傳輸的封包大小跟反應時間是呈現何種關係:    傳輸架構如下, 實驗的數據結果如下:
無論何種封包size, 每一個封包均傳50次求平均, 所得的平均結果為"平均時間", 而 50 次內花最長時間的為 "最長時間". 反之為 "最短時間"    封包長度        平均時間        最長時間        最短時間
0        350        438        297
100        371.8        453        296
200        400        469        344
300        384.4        453        312
400        393.8        437        360
500        387.6        422        344
600        390        423        375
700        412.4        453        375
800        400        437        360
900        443.8        484        407
1000        393.8        438        359
1100        400        422        390
1200        400        438        375
1300        403.2        438        375
1400        403.4        438        344
1500        178        203        156
1600        187.6        203        172
1700        184.4        218        156
1800        184.2        219        156
1900        181.2        203        156
2000        193.8        203        172
2100        187.6        204        171
2200        200        218        187
2300        197        235        172
2400        200        218        187
2500        206.2        235        172
2600        206.2        234        172
2700        209.4        235        172
2800        206        219        172
2900        284.4        297        250
3000        290.6        312        266
3100        287.6        312        266
3200        297        328        281
3300        293.6        312        266
3400        300        313        281
3500        303.2        328        297
3600        303.2        328        281
3700        300        328        281
3800        306.2        344        266
3900        293.8        329        281
4000        309.4        328        281
圖形如下: 實驗的結果是封包在大於1400 bytes 到 2800 bytes 之間反而要花費的傳輸時間較少, 有人知道為什麼嗎? 很奇怪, 1400 ~ 2800 剛好是介於 1個 MTU 及 2個 MTU 之間!!
avex
初階會員


發表:19
回覆:49
積分:43
註冊:2003-03-28

發送簡訊給我
#2 引用回覆 回覆 發表時間:2005-07-23 13:21:47 IP:218.163.xxx.xxx 未訂閱
應該很多人在寫網路傳輸程式, 沒有人知道為什麼嗎?
conundrum
尊榮會員


發表:893
回覆:1272
積分:643
註冊:2004-01-06

發送簡訊給我
#3 引用回覆 回覆 發表時間:2005-07-23 14:27:06 IP:220.132.xxx.xxx 未訂閱
先看看才知道為什麼 http://delphi.ktop.com.tw/topic.php?topic_id=31861 看了有為什麼 http://delphi.ktop.com.tw/quicksearch.exe/quicksearch?SearchStr=MTU http://www.wells.hk/ws_toolsdetail.php?tools_id=1103101899 Windows工具箱詳細資料 -------------------------------------------------------------------------------- 主題: 更改MTU值去加速上網 主題內容: MTU即為Maximum Transmission Unit,而每個單位為1 Byte,MTU是電腦在一段時間下,最高可以把資源傳送到網上的總容量。預設MTU值一般較少,為加大資料流量,可設定較大,但不要設定過大,否則出現Packet lost失掉資料的情況,反而拖慢速度。 先測試一下MTU值:在當接上寬頻後,在DOS模式下鍵入「ping -1 xxxx (MTU數值) www.xxxxxxx.com (網站)」去測試MTU值,然後出現:「Reply from xxx.xxx.xxx.xxx: bytes= “1462” time = 20ms TTL=251」,即表示資料傳送成功。MTU值可以由1462開始,然後加上去,重覆以上的測試,直至出現「Request Time Out」為止。例如MTU值測試到1500為最佳,但這值在接往不同的網址有不同結果,所以要多測試幾個不同網址以確定沒問題,然後以這值在RASPPPoE的設定值內加入。 【轉貼】Microsoft Windows 2000 TCP/IP ??詳細 http://delphi.ktop.com.tw/topic.php?TOPIC_ID=64978
avex
初階會員


發表:19
回覆:49
積分:43
註冊:2003-03-28

發送簡訊給我
#4 引用回覆 回覆 發表時間:2005-07-23 17:12:48 IP:218.163.xxx.xxx 未訂閱
首先, 很謝謝 conundrum 的回答, ^_^ 我就是在做 MTU 的實驗才有這個結果的. 但是, 大家也看到了, 速度加快竟然是過了一個 MTU (1472 bytes) 才加快. 理論上, 當封包大於MTU時, 它是會被切成二個封包傳送, 所以傳送時間會增加才對, 但這個實驗卻得到不同的結果. 不論是用 Borland 的 TClientSocket/TServerSocket 或用 Indy 的TIdTCPClient/TIdTCPServer 結果曲線圖幾乎相同 程式非常的簡單, 應讓該不會出錯, 不知道大家寫的程式是否也有相同結果? 以 Indy 來說, 程式碼只是呼叫傳送/接收 stream 函式, 如下 [Client端] // 傳送的函式是呼叫 IdTCPClient->WriteStream(pStream, true, true, 0); [Server端] // 在 ServerExecute Event 中用相對應的 ReadStream 來讀取 AThread->Connection->ReadStream(pStream, -1, false); 我知道 802.3 10MHz 的網路會有 padding 的現象, 也就是不滿 64 bytes 會被填滿 64, 但應該與本題無關才對. 不知道是不是在 Router 或 hub 中是不是又有 priority 這種現象, 在這裡發問是想也許站上有人在開發網路卡之類的工程師, 可以解惑 先謝謝啦~~
conundrum
尊榮會員


發表:893
回覆:1272
積分:643
註冊:2004-01-06

發送簡訊給我
#5 引用回覆 回覆 發表時間:2005-07-23 20:11:06 IP:218.175.xxx.xxx 未訂閱
連不上一些網站的處理方法 MTU 修改 http://alfa.mtm.ks.edu.tw/computer/vbird_linux/linux_server/0140networkcommand.htm#MTU   http://www.microsoft.com/taiwan/msclub/member/TIPS/Spring_2001/tip1to3/tip1to3_2.htm    國立中山大學電機工程學系碩士論文 http://etd.lib.nsysu.edu.tw/ETD-db/ETD-search/getfile?URN=etd-0801103-195712&filename=etd-0801103-195712.pdf    此文寫的還真不錯喔 http://www.ns-bbs.com/teach/list.asp?id=87   如果封包沒有被切割﹐那麼 FO 的值為“0”。 http://www.ns-bbs.com/teach/list.asp?id=88    Indy及Borland 附的TCP socket 元件作傳輸實驗 如果說你也知道 你說的東西他底層與系統如何運作 才能談網路卡把  MTU 為什麼每一台都不一定 除了網路設備還有很多因素 就如網路卡是使用AUTO或100雙工等都會不一樣的 http://delphi.ktop.com.tw/topic.php?TOPIC_ID=75495 http://delphi.ktop.com.tw/topic.php?topic_id=71606 http://delphi.ktop.com.tw/topic.php?topic_id=50990 你可以使用比較純手工的vcl來了解如 ics套件 http://www.overbyte.be/frame_index.html 不然就真的手工打造啦 哈哈     
引言:在這裡發問是想也許站上有人在開發網路卡之類的工程師, 可以解惑
應該有把 不過只有等運氣了 也可以試試8866網友的tool玩玩 或思科資料把
avex
初階會員


發表:19
回覆:49
積分:43
註冊:2003-03-28

發送簡訊給我
#6 引用回覆 回覆 發表時間:2005-07-25 22:05:59 IP:220.140.xxx.xxx 未訂閱
儘管我問了智邦的工程師, 還是沒人知道. 但可以確定的一件事是, hub, router 只檢視 packet type. 不過, 若不是 hub 的問題, 應該存在程式上有什麼東西在搞鬼.     最後, 我找到問題所在了,在 win socket 傳輸裡面存在著一種叫 "擁塞控制演算法" 的東西, 它不是縮小傳輸的視窗,就是限制小的資料元。normally 是 enable. disable 它就可以了. 雖然 conundrum 沒有講到正確的問題所在, 但我還是很感謝他的幫忙, 所以 分數當然還是給他囉, 謝啦~~
conundrum
尊榮會員


發表:893
回覆:1272
積分:643
註冊:2004-01-06

發送簡訊給我
#7 引用回覆 回覆 發表時間:2005-07-26 07:36:06 IP:218.175.xxx.xxx 未訂閱
avex 你好 1 感恩感恩 2 請問一下你有去測試我po的網站嗎? 題外話 1 進入 http://www.speedguide.net/ 2 點選TCP/IP Analyzer 產生數據 庵的 MTU = 1492 MTU is optimized for PPoE DSL broadband. If not, consider raising MTU to 1500 for optimal throughput. MSS = 1452 MSS is optimized for PPPoE DSL broadband. If not, consider raising MTU to 1500 for maximum throughput. Default Receive Window (RWIN) = 373160 RWIN Scaling (RFC1323) = 3 bits (scale factor of 6) Unscaled Receive Window = 46645 For optimum performance, consider changing RWIN to a multiple of MSS. Other values for RWIN that might work well with your current MTU/MSS: 511104 (MSS x 44 * scale factor of 8) 255552 (MSS x 44 * scale factor of 4) 127776 (MSS x 44 * scale factor of 2) 63888 (MSS x 44) bandwidth * delay product (Note this is not a speed test): Your RcvWindow limits you to: 14926.4 kbps (1865.8 KBytes/s) @ 200ms Your RcvWindow limits you to: 5970.56 kbps (746.32 KBytes/s) @ 500ms MTU Discovery (RFC1191) = ON Time to live left = 23 hops TTL value is ok. Timestamps (RFC1323) = Timestamps (RFC1323) = ON Note: Timestamps add 12 bytes to the TCP header of each packet, reducing the space available for useful data. Selective Acknowledgements (RFC2018) = ON IP type of service field (RFC1349) = 00000000 (0)
系統時間:2024-05-17 9:50:34
聯絡我們 | Delphi K.Top討論版
本站聲明
1. 本論壇為無營利行為之開放平台,所有文章都是由網友自行張貼,如牽涉到法律糾紛一切與本站無關。
2. 假如網友發表之內容涉及侵權,而損及您的利益,請立即通知版主刪除。
3. 請勿批評中華民國元首及政府或批評各政黨,是藍是綠本站無權干涉,但這裡不是政治性論壇!