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

Joel Sherrill joel.sherrill at
Wed May 30 19:29:40 UTC 2012

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 [mailto:rtems-users-bounces at] 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
> 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:
>> 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<>/*
>> _______________________________________________
>> rtems-users mailing list
>> rtems-users at

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

More information about the users mailing list