Yes, the sender connects to the board through an ad-hoc connection and only one send() call returns all the necessary bytes sent.<br><br>The ethernet MAC is 10Mbit full-duplex. I wonder if there is a 5Mbit bandwidth limit for each side of the communication as this would explain the half increase (0.6s instead of the calculated 0.3s assuming 10Mbit) i observe with Eric's solution.<br>
<br><br>Best,<br>JM<br><br><br><br><div class="gmail_quote">On Wed, Feb 9, 2011 at 6:29 PM, Eric Norum <span dir="ltr"><<a href="mailto:wenorum@lbl.gov">wenorum@lbl.gov</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<div class="im"><br>
On Feb 9, 2011, at 10:06 AM, Joćo Rasta wrote:<br>
<br>
> Hi all,<br>
><br>
> I implemented Yann's sugestion and it seemed to take a lot of time to return. So i profiled the recv() routine with the MSG_WAITALL flag and returned 5.70 seconds! With Eric's sugestion, the whole data is read in 0.60 seconds. This is odd, i would expect that, since apparently there are more system calls with Eric's method, recv() would be faster.<br>

><br>
> Any idea why this is happening?<br>
<br>
<br>
><br>
> Moreover, i'm transferring 436160*8 = 3489280 bits, so i would expect the total data read to happen in 3489280/10485760 = 0.33 seconds, given that i have a 10Mbit ethernet configuration. I don't think context switching for a couple of system calls is that heavy, what can be causing the 0.27 second overhead with Eric's solution?<br>

<br>
</div>1) Can the sender pump the data out at full speed?<br>
2) TCP acknowledgements have to be formed and transmitted.<br>
3) There's overhead in computing the IP and TCP checksums for each packet in and out.<br>
<font color="#888888"><br>
--<br>
</font><div><div></div><div class="h5">Eric Norum<br>
<a href="mailto:wenorum@lbl.gov">wenorum@lbl.gov</a><br>
<br>
</div></div></blockquote></div><br>