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

[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秒

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

--
※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 112.104.118.100
※ 文章網址: https://www.ptt.cc/bbs/C_and_CPP/M.1433380362.A.1EB.html
※ 編輯: r596twy (112.104.118.100), 06/04/2015 09:17:01
→ anyoiuo: 傳"檔案"用UDP你可能得先了解UDP，另外你應該是共用同個
→ anyoiuo: server socket吧? 我想他應該同時間只能有一人去讀取!
UDP，不確定有無誤解，我目前對它的了解有:
1.無掉封包重傳機制 (TCP才有)
2.與TCP不同的是，將大多欄位拿來給檔案內容(payload)，
  所以同時可傳送更多的檔案內容
3.UDP不管接收順序和有無掉封包，所以不用等Client端傳確認訊息，會一直傳

server socket我是只有用一個，
因為我原本是希望TCP可以做到N個threads同時傳送和接收封包
但TCP似乎要在socket中開N個ports(不確定是否認知錯誤)
而UDP不像TCP會有很多耽擱時間(許多機制導致)
且以為UDP是Server傳完一個封包就一直傳，不管Client是否已收完(此段不確定)
所以才打算在UDP上試試看，而結果似乎不對

目前我可能的猜測是:
1.Context switching，但正常不是一個核心一個thread嗎？還會有這問題？
2.Single connection，同一時間只有傳一個封包，但如果是如此，怎還有時間反而上升的情形？

現在有開多個threads同時接收封包的實際應用嗎？
如果有的話，想請問他們是怎作的？
※ 編輯: r596twy (112.104.118.100), 06/04/2015 09:52:43
→ appleway: ios 只有一個network thread. just like media thread
不太確定你的意思，不知道有沒誤解
是說作業系統可能有差？還是說網路傳輸封包對於ios只能一筆收完才能傳下一筆？
我是Win7 64-bit
測過簡單的i = i + 1運算兩百萬次
是發現時間的確有下降
也檢查thread編號的確有各別在執行
但不確定這樣的結果是否也在傳輸方面適用
※ 編輯: r596twy (112.104.118.100), 06/04/2015 10:08:21
→ appleway: sorry 我以爲我在mac dev版
推 ctrlbreak: 會不會寫檔變慢的....XD
我的寫法是接收一次寫一次，如果改成全部接收後再寫入應該會變快
但一個thread和多個threads感覺總寫入次數應該會很接近才是
所以我如果這樣改，可能是全部時間都有縮短，
但多個thtreads時間比一個thread還耗時好像還是沒辦法解決？

→ azureblaze: 要不要多插幾條網路線看看
→ azureblaze: IO類的東西硬體側thread超少很正常
→ azureblaze: 你派10億人過去還不是都卡同一個窗口
→ azureblaze: 海關還會大塞車
→ azureblaze: IO通常少量大包資料效率會比較好
多插幾條網路線跟在socket多開幾個ports和connect去連接是一樣效果嗎？
還是說這兩者是要並行一起作的？
※ 編輯: r596twy (112.104.118.100), 06/04/2015 10:57:59
→ sos0214: 用IOCP?
不好意思，不太確定你說得是啥，
可以說清楚點嗎？
感謝你

推 ctrlbreak: 處理同一件事用multithread會變慢是正常的, 邏輯沒
→ ctrlbreak: 相依性才有加速效果
→ ctrlbreak: 題外話UDP在現實網路環境其實很不穩, 用它傳檔感覺不
→ ctrlbreak: 太適合
有點不確定你說的邏輯相依性是甚麼
是指thread與thread之間所作的事情關連性叫邏輯相依性？
如果是的話，應該是要彼此無關，不會要等彼此的結果出來所拖累
multi-thread才會加快不是嗎？

然後我會想用UDP的原因在於
因為我最終是要傳遞影像經過壓縮後的bin檔
類似要作影像串流的網路傳輸
而我之前查過文獻得知
目前大多影像串流和線上視訊等等
大多為了速度而犧牲可靠度選擇UDP
當然也有如Youtube
是用TCP來搭配應用
※ 編輯: r596twy (112.104.118.100), 06/04/2015 13:11:47
推 fireslayer: 他們都是同一條線，沒有那種開n thread網路速度就n倍
→ fireslayer: 的，可以的話中華電信就不用賺了
我想減少的是接收時間，不是傳輸時間

→ MOONRAKER: 那是streaming播放才用UDP 你不能保證封包正確性檔案收
→ MOONRAKER: 下來checksum都不對 播放直接吃format error
→ MOONRAKER: streaming影格壞了跳過就好 你影片檔這樣搞會爛掉
我知道UDP的缺點，我上面回覆有說啦，我這實驗主要是為了影像串流(streaming)而作的
所以影格丟失就丟失，無所謂
而checksum這邊的敘述怎有點怪怪的
checksum不是驗證收到封包是否正確的一種方法嗎？
既然已到播放那一環了，那表示接收封包被視為正確的
才會把內容送去decoder解碼並播放
這checksum跟format error沒半點關係阿

然後會造成不能播放的原因通常有兩點，
1.Intra frame丟失，造成部分需要參考此畫面資訊重建的畫面不能解碼並播放
  必須到下一個group of picture(GOP)才可以繼續
2.描述影像相關參數丟失(如長寬比、畫面顯現時間等)，而造成整段影片不能解碼
  但現在影像編碼都有良好的糾錯以及專為此情況處理的傳送機制，
  所以這情況基本上很難發生

→ anyoiuo: 想想窗口(Port)只有一個，不會因為你有多少人(Thread)而
→ anyoiuo: 變快。
→ anyoiuo: 要變快應該去調教接收buffer與系統網路buffe的大小
→ anyoiuo: 如linux中net.core.rmem_max
→ anyoiuo: 想串流的話應該走RTP/RTSP/RTCP之類的protocal
→ anyoiuo: 可以去看看live555、VLC之類的open source
→ anyoiuo: 另外多網卡 + network bonding應該也能有效提升速率
live555和VLC我也正在研究它們是如何運作的
另外RTP/RTCP和RTSP是應用層方面的
跟傳輸層方面的TCP/UDP是分開考慮
彼此間只是相互協作關係
而目前我是想觀察一些現象，所以先從傳輸層方面開始觀察
傳輸層方面的實驗有一定了解後，才進一步將應用層拿進來考慮

多網卡感覺應該可以提速，
那如果我同時開多個port，也能達到提速效果嗎？

推 Qbsuran: 阿就漏斗啊 裝水量再大 出水量還是不變
有考慮到這可能是造成問題的原因，Single connection
但是如果真是這問題，
既然總水量一樣，換句話說就是總封包個數一樣
且出水速度一樣，換句話說就是封包接收時間一樣
那單一thread和多個threads彼此花費的時間應該要相近
但現在看到的卻不是這樣的結果...
※ 編輯: r596twy (112.104.118.100), 06/05/2015 08:31:57
※ 編輯: r596twy (112.104.118.100), 06/05/2015 08:32:47
※ 編輯: r596twy (112.104.118.100), 06/05/2015 08:36:05
※ 編輯: r596twy (112.104.118.100), 06/05/2015 08:36:36
※ 編輯: r596twy (112.104.118.100), 06/05/2015 08:49:53
→ azureblaze: "overhead"
→ anyoiuo: 不可能相近因為socket send/recv 都是 Thread safety
→ anyoiuo: 本身就是atomic operation所以，同時間只會有1個thread
→ anyoiuo: 在讀或寫，後面的Thread都在排隊，多了排隊跟切換的時間
→ anyoiuo: 所以你每次能read buffer的大小，會有直接的影響，因為每
→ anyoiuo: 讀完一次，還沒讀完馬上就要再換人。
→ anyoiuo: 多connection應該能有一點改善才對，但仍局限於網卡頻寬
→ anyoiuo: 另外live555那些TCP, UDP都有支援!
→ fireslayer: 你的情況接收時間最快上限就是傳輸時間 是被網卡跟線
→ fireslayer: 路侷限住的 多thread不會變快 而會變慢的原因樓上說的
→ samuelcdf: thread是增加吞吐量, 你要比應該是比檔案開thread下載
→ samuelcdf: 的時間vs檔案ㄧ前一後下載的時間和
→ samuelcdf: 假設下載1MB的人不幸比下載9MB的另一個人晚一點開始
→ samuelcdf: 多thread會讓兩人無感； 單thread會讓1MB的人很有感
→ samuelcdf: 因為他要先等9MB傳完