TCP issue with large packet under RTEMS

Yann Sionneau yann at minet.net
Wed Feb 9 18:36:36 UTC 2011


Maybe try looking at the network traffic with wireshark to see if 
everything is behaving OK.

I do not understand the difference of timing at all.
Maybe it's due to some priority in the RTEMS tasks, I don't know.

Le 09/02/11 18:06, João Rasta a écrit :
> Hi all,
>
> 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.
>
> Any idea why this is happening?
>
> 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?
>
> Best,
> JM
>
> On Wed, Feb 9, 2011 at 5:41 PM, Eric Norum <wenorum at lbl.gov
> <mailto:wenorum at lbl.gov>> wrote:
>
>     On Feb 9, 2011, at 9:26 AM, Yann Sionneau wrote:
>
>      > Hi Joao,
>      >
>      > The fact that recv() can return before receiving everything you
>     expect, and is non-blocking, is the standard way of functionning for
>     recv().
>      >
>      > This is the POSIX way, if you do man recv on a Linux system for
>     example you will see that this behaviour is documented.
>      >
>      > 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.
>      >
>      > 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.
>
>     Yes, I believe that it is.
>
>     --
>     Eric Norum
>     wenorum at lbl.gov <mailto:wenorum at lbl.gov>
>
>



More information about the users mailing list