作者:
r596twy (湯姆熊)
2015-06-04 09:12:38開發平台(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秒
作者: anyoiuo 2015-06-04 09:21:00
傳"檔案"用UDP你可能得先了解UDP，另外你應該是共用同個server socket吧? 我想他應該同時間只能有一人去讀取!
作者: appleway (蘋果愛天空) 2015-06-04 10:01:00
ios 只有一個network thread. just like media threadsorry 我以爲我在mac dev版
作者: ctrlbreak 2015-06-04 10:36:00
會不會寫檔變慢的....XD
要不要多插幾條網路線看看IO類的東西硬體側thread超少很正常你派10億人過去還不是都卡同一個窗口海關還會大塞車IO通常少量大包資料效率會比較好
作者:
sos0214 (kaleidoscope)
2015-06-04 11:38:00用IOCP?
作者: ctrlbreak 2015-06-04 11:49:00
處理同一件事用multithread會變慢是正常的, 邏輯沒相依性才有加速效果題外話UDP在現實網路環境其實很不穩, 用它傳檔感覺不太適合
他們都是同一條線，沒有那種開n thread網路速度就n倍的，可以的話中華電信就不用賺了
那是streaming播放才用UDP 你不能保證封包正確性檔案收下來checksum都不對 播放直接吃format errorstreaming影格壞了跳過就好 你影片檔這樣搞會爛掉
作者: anyoiuo 2015-06-04 17:29:00
想想窗口(Port)只有一個，不會因為你有多少人(Thread)而變快。要變快應該去調教接收buffer與系統網路buffe的大小如linux中net.core.rmem_max想串流的話應該走RTP/RTSP/RTCP之類的protocal可以去看看live555、VLC之類的open source另外多網卡 + network bonding應該也能有效提升速率
作者:
Qbsuran (Qbsuran)
2015-06-04 22:28:00阿就漏斗啊 裝水量再大 出水量還是不變
作者: anyoiuo 2015-06-05 09:25:00
不可能相近因為socket send/recv 都是 Thread safety本身就是atomic operation所以，同時間只會有1個thread在讀或寫，後面的Thread都在排隊，多了排隊跟切換的時間所以你每次能read buffer的大小，會有直接的影響，因為每讀完一次，還沒讀完馬上就要再換人。多connection應該能有一點改善才對，但仍局限於網卡頻寬另外live555那些TCP, UDP都有支援!
你的情況接收時間最快上限就是傳輸時間 是被網卡跟線路侷限住的 多thread不會變快 而會變慢的原因樓上說的
thread是增加吞吐量, 你要比應該是比檔案開thread下載的時間vs檔案ㄧ前一後下載的時間和假設下載1MB的人不幸比下載9MB的另一個人晚一點開始多thread會讓兩人無感； 單thread會讓1MB的人很有感因為他要先等9MB傳完