TCP issue with large packet under RTEMS

[João Rasta]

Yes, the sender connects to the board through an ad-hoc connection and only
one send() call returns all the necessary bytes sent.

The ethernet MAC is 10Mbit full-duplex. I wonder if there is a 5Mbit
bandwidth limit for each side of the communication as this would explain the
half increase (0.6s instead of the calculated 0.3s assuming 10Mbit) i
observe with Eric's solution.


Best,
JM



On Wed, Feb 9, 2011 at 6:29 PM, Eric Norum <wenorum at lbl.gov> wrote:

>
> On Feb 9, 2011, at 10:06 AM, João Rasta wrote:
>
> > 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?
>
> 1) Can the sender pump the data out at full speed?
> 2) TCP acknowledgements have to be formed and transmitted.
> 3) There's overhead in computing the IP and TCP checksums for each packet
> in and out.
>
> --
> Eric Norum
> wenorum at lbl.gov
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/users/attachments/20110209/ef344886/attachment-0001.html>