TCP issue with large packet under RTEMS

João Rasta freakforever at
Wed Feb 9 18:06:13 UTC 2011

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> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the users mailing list