Joćo,<div><br></div><div>Try to put the network task priority higher than the application task priority.</div><div>Just a guess.</div><div><br></div><div>--Wendell.</div><div><br></div><div><br><div class="gmail_quote">2012/5/18 Thomas Doerfler <span dir="ltr"><<a href="mailto:Thomas.Doerfler@embedded-brains.de" target="_blank">Thomas.Doerfler@embedded-brains.de</a>></span><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi,<br>
<br>
obviously you have investigated the problem on application level very<br>
thoroughly. I have no idea right now what might be the reason for your<br>
system's behaviour, but it would help if you could provide some more<br>
information:<br>
<br>
- which rtems version are you using?<br>
- how do you configure the networking stack? There should be a few data<br>
structures in the Init module of your application, appending them to<br>
your mail might give more insight.<br>
<br>
wkr,<br>
<br>
Thomas.<br>
<br>
Am 18.05.2012 22:47, schrieb Joćo Paulo Scalćo Martins:<br>
<div class="im">> Hello friends, how are you doing?<br>
><br>
> I'm working with a RTEMS-based system on a Single Board Computer,<br>
> (Advantech PC104 - PCM 4153). The processor is the AMD Geode LX800. The<br>
> system requires ethernet TCP/IP communication between the SBC and a<br>
> Linux Destop. To implement this issues, I used the fxp driver (found in<br>
> libbsdport library), because the network chip is the Intel 82551 ER.<br>
><br>
> The software was written, and it all worked out in the initial tests.<br>
> The communication between the SBC and the Linux (client) was efficient<br>
> and stable. However, the TCP/IP packets changed were very small in size,<br>
> 15 bytes. Our system can, eventually, send and receive packets of 250 or<br>
> more bytes of data. I decided to do a test to see these situations.<br>
><br>
> That's when the trouble began. I wrote several programs, some very<br>
> simple (echo client-server), other more complex (four tasks), and all<br>
</div>> had the same problem of *_packet fragmentation_*. I analyzed the<br>
<div class="im">> communication with a sniffer (Wireshark) and I will describe the<br>
> observations:<br>
><br>
</div>> * As long as the data packets were smaller than 95 bytes, the<br>
<div class="im">> connection was perfect. The period of one single iteration was about<br>
> 150 microsseconds.<br>
><br>
</div>> * When the SBC-RTEMS needs to send more than 95 bytes, the data is<br>
> fragmented on 2 frames. The first has *_96 bytes_*, and the second<br>
<div class="im">> has the remaining. For the application level, this issue is<br>
> transparent, BUT, between one frame and another, the elapsed time is<br>
> about 40 milliseconds, whereas in the previous situation, it was<br>
> about 150 microsseconds. Finally, the speed of the system dropped<br>
> dramatically.<br>
</div>> o Detail: the second frame is sent only a few microsseconds after<br>
<div class="im">> the client (Linux Desktop) sends an ACK packet.<br>
><br>
</div>> * When the stream of data is bigger than 200 bytes (I don't exactly<br>
<div class="im">> this number) the system collapses. The SBC can even send the large<br>
> packets in one frame, but after a few minutes, some retransmitions<br>
> occurs (from both parts) and the connection undergoes a reset.<br>
><br>
> I looked for a similar problem in the RTEMS mailing list, and found the<br>
> following<br>
> 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><br>
> But the numerical values are a bit different, and I didn't found the files.<br>
><br>
> I apologize if maybe my problem is not related to RTEMS and is just a<br>
> communication problem. However, we have done tests on the same hardware<br>
> with other operating systems (Linux, NetBSD) and the communication was<br>
> stable and efficient. Even with RTEMS, I made several types of<br>
> programs, but the problem remained the same.<br>
><br>
> Thanks for your help!<br>
><br>
> Best regards from Brazil.<br>
><br>
> Joao Paulo Martins<br>
</div>> */Brazilian Synchrotron Light Laboratory - LNLS <<a href="http://www.lnls.br" target="_blank">http://www.lnls.br</a>>/*<br>
><br>
><br>
> _______________________________________________<br>
> rtems-users mailing list<br>
> <a href="mailto:rtems-users@rtems.org">rtems-users@rtems.org</a><br>
> <a href="http://www.rtems.org/mailman/listinfo/rtems-users" target="_blank">http://www.rtems.org/mailman/listinfo/rtems-users</a><br>
<br>
<br>
--<br>
--------------------------------------------<br>
embedded brains GmbH<br>
Thomas Doerfler<br>
Obere Lagerstrasse 30<br>
D-82178 Puchheim<br>
Germany<br>
email: <a href="mailto:Thomas.Doerfler@embedded-brains.de">Thomas.Doerfler@embedded-brains.de</a><br>
Phone: <a href="tel:%2B49-89-18908079-2" value="+4989189080792">+49-89-18908079-2</a><br>
Fax: <a href="tel:%2B49-89-18908079-9" value="+4989189080799">+49-89-18908079-9</a><br>
PGP: Public key available on request.<br>
<br>
Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.<br>
_______________________________________________<br>
rtems-users mailing list<br>
<a href="mailto:rtems-users@rtems.org">rtems-users@rtems.org</a><br>
<a href="http://www.rtems.org/mailman/listinfo/rtems-users" target="_blank">http://www.rtems.org/mailman/listinfo/rtems-users</a><br>
</blockquote></div><br></div>