TCP/IP packet fragmentation issue

[João Paulo Scalão Martins]

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.
      - 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>*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/users/attachments/20120518/51c2bc92/attachment.html>