Re: [問題] 使用multi-thread去接收封包反而慢??

[r596twy (湯姆熊)]

※ 引述《r596twy (湯姆熊)》之銘言：
: 開發平台(Platform): (Ex: VC++, GCC, Linux, ...)
: Visual studio 2013
: 額外使用到的函數庫(Library Used): (Ex: OpenGL, ...)
: 問題(Question)：
: 寫了Socket的程式，Server端傳檔案，然後Client端接收並寫入檔案
: Multi-thread開N個threads同時去分別接收UDP封包，
: 換句話說，想要將封包拆成N份並同時接收
: 所以預期是希望所需總接收時間會下降
: 但我發現單一thread接收的時間反而比較快...
: 不清楚這可能的問題是甚麼
: 會是因為context switching過多??
: 如果是的話我有辦法從自己的code看出來嗎??
: 補充說明(Supplement)：
: API是使用OpenMP
: 舉個目前測試出的結果，讓大家看看能不能更清楚我可能忽略或做錯的狀況
: thread個數為1時
: 接收10MB的檔案約須時2.5秒
: thread個數為2時
: 若分別接收9MB和1MB，共須時3秒
: 若分別接收5MB和5MB，共須時5秒

透過將多個port打開並同時傳輸後，時間得到預期的結果了

但做一些實驗時，又出現一些怪現象以及一些小疑問：

問題1：
　因為測試的Server和Client各是雙核心CPU，所以各開兩個threads去同時傳送和接收
　
　但問題來了，檔案如果傳超過10MB以上，會直接斷線而無法傳完

　而且整個網路有一小段時間會呈現網路斷開狀態無法上網...

  頻寬沒有被吃光，但網路與socket連線卻斷開了，不清楚是甚麼原因造成這樣


問題2：
　我的網路環境是2MB/s，但我用流量觀測軟體去看，發現每秒只用了300KB

  我是用Ws2_32.lib和WinSock2.h，是這lib本身有預設傳輸速度嗎？

  如果是的話我該如何去調整呢？


問題3：
　我是用UDP在傳輸01格式的binary code，目前是用sendto和recvfrom來達成

　每次傳輸8個bits，也就是"10010101"諸如此類長度的char出去

  而我想問的是，有看到網路上傳輸檔案似乎也有用write/read來達成

　這跟sendto/recvfrom有啥應用上以及傳輸封包上的差異嗎？

--
╔《新版十二生肖》═════════════════════════════╗
║                                   ◣◣           ˍ                      ║
 ●●╰‧‧╯◣  ◢ [ ] ιι .  .◣ - - ◣  ˍ▁  ◢﹎◣▁▂                ║
◢''    ..    '〒' '. ' '  '  ξ ▌ . . ≡◢'◎@@ ●﹏●★' ◣ ˊ▄ˋ ★︰  ║
 ‵′/  ██╯ █/   ▲╭≡╮    ▃  ￣█ㄟ  @@@@  ◣◢ ◥█◤ ˋ▄ˊ ‥    ║
╚═══" " ════════════ "═"══"═"══╯══════liszt1025╝

--
※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 112.104.118.100
※ 文章網址: https://www.ptt.cc/bbs/C_and_CPP/M.1433956316.A.5A5.html
→ bibo9901: 一般網速的單位是 bits/sec 不是 bytes/sec
→ bibo9901: 2M bits/sec = 250K bytes/sec 你已經用到全部頻寬了
嗯嗯，我上面的數字都已經轉換為byte了

所以我頻寬是2MB/s，然後每秒用250KB沒錯

頻寬並沒有被吃完

→ anyoiuo: udp packet應該可以設Time to live估計，你已經塞爆了!
→ anyoiuo: 話說每次8bits有點太少了
→ anyoiuo: 如果你是用同一個hinet帳號上網，頻寬還得在對分。
→ anyoiuo: 而且8bits真的太少了, udp header都比你資料來的大
UDP可用Time to liveg目的是為了？願聞其詳～

了解，我現在正嘗試用256B或512B的大小來傳

只是我發現，雖然固定大小的檔案內容，

但如果一次丟太大，接收時間會突然暴增

有點不清楚發生的原因是甚麼
※ 編輯: r596twy (140.113.208.63), 06/11/2015 17:23:19
→ anyoiuo: 控制封包存活時間，當封包過多生存時間太長網路會癱瘓