开发平台(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秒

传"档案"用UDP你可能得先了解UDP，另外你应该是共用同个server socket吧? 我想他应该同时间只能有一人去读取!

ios 只有一个network thread. just like media threadsorry 我以为我在mac dev版

会不会写档变慢的....XD

要不要多插几条网络线看看IO类的东西硬件侧thread超少很正常你派10亿人过去还不是都卡同一个窗口海关还会大塞车IO通常少量大包资料效率会比较好

用IOCP?

处理同一件事用multithread会变慢是正常的, 逻辑没相依性才有加速效果题外话UDP在现实网络环境其实很不稳, 用它传档感觉不太适合

他们都是同一条线，没有那种开n thread网络速度就n倍的，可以的话中华电信就不用赚了

那是streaming播放才用UDP 你不能保证封包正确性档案收下来checksum都不对 播放直接吃format errorstreaming影格坏了跳过就好 你影片档这样搞会烂掉

想想窗口(Port)只有一个，不会因为你有多少人(Thread)而变快。要变快应该去调教接收buffer与系统网络buffe的大小如linux中net.core.rmem_max想串流的话应该走RTP/RTSP/RTCP之类的protocal可以去看看live555、VLC之类的open source另外多网卡 + network bonding应该也能有效提升速率

阿就漏斗啊 装水量再大 出水量还是不变

"overhead"

不可能相近因为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传完