TCP/IP packet fragmentation issue

Fri May 18 23:04:19 UTC 2012

João,

Regarding your application, it seems that your are implementing a kind of
SEND/ACK protocol over TCP/IP, isn't it?

What about using UDP/IP instead? For such tiny (< 500 bytes) and frequent
packets, maybe UDP would be more appropriate for you application, since you
already have your own "acknowledge-based" app protocol.

Please, don't get me wrong! I'm not telling what you have or not have to
do. This is just another guess! :-) I know this will not solve the TCP
fragmentation problem, but another test wont heart.

--Wendell.

2012/5/18 Wendell Silva <silvawp at gmail.com>

> João,
>
> Try to put the network task priority higher than the application task
> priority.
> Just a guess.
>
> --Wendell.
>
>
> 2012/5/18 Thomas Doerfler <Thomas.Doerfler at embedded-brains.de>
>
>> Hi,
>>
>> obviously you have investigated the problem on application level very
>> thoroughly. I have no idea right now what might be the reason for your
>> system's behaviour, but it would help if you could provide some more
>> information:
>>
>> - which rtems version are you using?
>> - how do you configure the networking stack? There should be a few data
>> structures in the Init module of your application, appending them to
>> your mail might give more insight.
>>
>> wkr,
>>
>> Thomas.
>>
>> Am 18.05.2012 22:47, schrieb 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.
>> >       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
>>
>>
>> --
>> --------------------------------------------
>> embedded brains GmbH
>> Thomas Doerfler
>> Obere Lagerstrasse 30
>> D-82178 Puchheim
>> Germany
>> email: Thomas.Doerfler at embedded-brains.de
>> Phone: +49-89-18908079-2
>> Fax: +49-89-18908079-9
>> PGP: Public key available on request.
>>
>> Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
>> _______________________________________________
>> rtems-users mailing list
>> rtems-users at rtems.org
>> http://www.rtems.org/mailman/listinfo/rtems-users
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/users/attachments/20120518/51c85532/attachment-0001.html>