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>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>Best,<br>JM<br><br><div class="gmail_quote">On Wed, Feb 9, 2011 at 5:41 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">On Feb 9, 2011, at 9:26 AM, Yann Sionneau wrote:<br>
<br>
> Hi Joao,<br>
><br>
> The fact that recv() can return before receiving everything you expect, and is non-blocking, is the standard way of functionning for recv().<br>
><br>
> This is the POSIX way, if you do man recv on a Linux system for example you will see that this behaviour is documented.<br>
><br>
> This is the correct behaviour of recv(), you have to run it inside a loop if you want to be sure to receive all the data you need.<br>
><br>
> On Linux there is a flag MSG_WAITALL that you can pass to recv() to make it wait untill it receives the amount of data you tell him to get. I don't know if it is implemented in RTEMS TCP/IP protocol stack.<br>
<br>
</div>Yes, I believe that it is.<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>