TCP issue with large packet under RTEMS

[João Rasta]

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> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/users/attachments/20110209/0362c087/attachment.html>