RES: TCP/IP packet fragmentation issue

[Wendell Pereira da Silva]

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

-- 

Mick Davis
Goanna Technologies Pty Ltd
+61 8 9444 2634