Patch review desired was Re: RES: TCP/IP packet fragmentation issue

[Joel Sherrill]

Chris and Eric.. comments on the patch?

On 05/30/2012 08:57 AM, Wendell Pereira da Silva wrote:
> Hi João,
>
> I'm curious on this issue. Have you applied the Mick's patch? Has it proved to be sufficient?
> Please, give us a feedback when possible.
>
> Thanks.
>
> --Wendell.
>
> -----Mensagem original-----
> De: rtems-users-bounces at rtems.org [mailto:rtems-users-bounces at rtems.org] Em nome de Mick Davis
> Enviada em: segunda-feira, 21 de maio de 2012 01:11
> Para: João Paulo Scalão Martins
> Cc: rtems-users at rtems.org
> Assunto: Re: TCP/IP packet fragmentation issue
>
> Hi
>
> A patch for rtems 4.10 is attached.  It implements the fix discussed in the mailing list thread you reference.  Writes a bit larger than MHLEN
> (98 bytes I think) won't get fragmented, at least not in this socket layer operation.
>
>
> On 19/05/12 04:47, João Paulo Scalão Martins wrote:
>> Hello friends, how are you doing?
>>
>> I'm working with a RTEMS-based system on a Single Board Computer,
>> (Advantech PC104 - PCM 4153). The processor is the AMD Geode LX800.
>> The system requires ethernet TCP/IP communication between the SBC and
>> a Linux Destop. To implement this issues, I used the fxp driver (found
>> in libbsdport library), because the network chip is the Intel 82551 ER.
>>
>> The software was written, and it all worked out in the initial tests.
>> The communication between the SBC and the Linux (client) was efficient
>> and stable. However, the TCP/IP packets changed were very small in
>> size,
>> 15 bytes. Our system can, eventually, send and receive packets of 250
>> or more bytes of data. I decided to do a test to see these situations.
>>
>> That's when the trouble began. I wrote several programs, some very
>> simple (echo client-server), other more complex (four tasks), and all
>> had the same problem of *_packet fragmentation_*. I analyzed the
>> communication with a sniffer (Wireshark) and I will describe the
>> observations:
>>
>>    * As long as the data packets were smaller than 95 bytes, the
>>      connection was perfect. The period of one single iteration was about
>>      150 microsseconds.
>>
>>    * When the SBC-RTEMS needs to send more than 95 bytes, the data is
>>      fragmented on 2 frames. The first has *_96 bytes_*, and the second
>>      has the remaining. For the application level, this issue is
>>      transparent, BUT, between one frame and another, the elapsed time is
>>      about 40 milliseconds, whereas in the previous situation, it was
>>      about 150 microsseconds. Finally, the speed of the system dropped
>>      dramatically.
>>        o Detail: the second frame is sent only a few microsseconds after
>>          the client (Linux Desktop) sends an ACK packet.
>>
>>    * When the stream of data is bigger than 200 bytes (I don't exactly
>>      this number) the system collapses. The SBC can even send the large
>>      packets in one frame, but after a few minutes, some retransmitions
>>      occurs (from both parts) and the connection undergoes a reset.
>>
>> I looked for a similar problem in the RTEMS mailing list, and found
>> the following topic:
>> http://www.rtems.com/ml/rtems-users/2004/june/msg00013.html
>> But the numerical values are a bit different, and I didn't found the files.
>>
>> I apologize if maybe my problem is not related to RTEMS and is just a
>> communication problem. However, we have done tests on the same
>> hardware with other operating systems (Linux, NetBSD) and the
>> communication was stable and efficient. Even with RTEMS, I made
>> several types  of programs, but the problem remained the same.
>>
>> Thanks for your help!
>>
>> Best regards from Brazil.
>>
>> Joao Paulo Martins
>> */Brazilian Synchrotron Light Laboratory - LNLS<http://www.lnls.br>/*
>>
>>
>> _______________________________________________
>> rtems-users mailing list
>> rtems-users at rtems.org
>> http://www.rtems.org/mailman/listinfo/rtems-users


-- 
Joel Sherrill, Ph.D.             Director of Research&   Development
joel.sherrill at OARcorp.com        On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
     Support Available             (256) 722-9985