TCP issue with large packet under RTEMS

[Yann Sionneau]

Ignore my previous e-mail, you have 10 Mbits/sec up and down, 
simultaneously.

Le 09/02/11 19:02, Yann Sionneau a écrit :
> 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.
> _______________________________________________
> rtems-users mailing list
> rtems-users at rtems.org
> http://www.rtems.org/mailman/listinfo/rtems-users