TCP/IP packet fragmentation issue
silvawp at gmail.com
Fri May 18 22:50:50 UTC 2012
Try to put the network task priority higher than the application task
Just a guess.
2012/5/18 Thomas Doerfler <Thomas.Doerfler at embedded-brains.de>
> 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
> - 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.
> 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
> > 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
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the users