TCP issue with large packet under RTEMS
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?
> 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
> > 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
> Yes, I believe that it is.
> Eric Norum
> wenorum at lbl.gov <mailto:wenorum at lbl.gov>
More information about the users