TCP issue with large packet under RTEMS

Yann Sionneau yann at minet.net
Wed Feb 9 19:02:48 UTC 2011


If you say 10Mbit full-duplex it means you have a total of 10 Mbit/s 
bandwidth, and both side can talk at the same time.

But you can just send data and receive nothing if you want, and then you 
would send at 10 Mbits/sec using the total bandwith for sending.

But bear in mind that even if you just send, you *will* receive datas, 
it's part of the TCP protocol (SYN, ACK, SYN ACK, RST and stuff).

But usually TCP overhead is neglictible compared to the real payload 
when you do speed calculus.

Le 09/02/11 18:48, João Rasta a écrit :
> 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
> <mailto: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.



More information about the users mailing list