Hello friends, how are you doing?<br><div><br></div><div>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.</div>
<div><br></div><div>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. </div>
<div><br></div><div>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 <b><u>packet fragmentation</u></b>. I analyzed the communication with a sniffer (Wireshark) and I will describe the observations: </div>
<div><br></div><div><ul><li>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.</li></ul></div><div><ul><li>When the SBC-RTEMS needs to send more than 95 bytes, the data is fragmented on 2 frames. The first has <b><u>96 bytes</u></b>, 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.</li>
<ul><li>Detail: the second frame is sent only a few microsseconds after the client (Linux Desktop) sends an ACK packet.</li></ul></ul></div><div><ul><li>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.</li>
</ul></div><div>I looked for a similar problem in the RTEMS mailing list, and found the following topic: <a href="http://www.rtems.com/ml/rtems-users/2004/june/msg00013.html" target="_blank">http://www.rtems.com/ml/rtems-users/2004/june/msg00013.html</a> </div>
<div>But the numerical values are a bit different, and I didn't found the files.</div><div><br></div><div>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.</div>
<div><br></div><div>Thanks for your help!</div><div><br></div><div>Best regards from Brazil.</div><div><br>Joao Paulo Martins</div><div><b><i>Brazilian Synchrotron Light Laboratory - <a href="http://www.lnls.br">LNLS</a></i></b></div>