Socket API send command packaging up data

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

Socket API send command packaging up data

Mike Danby

Hello,

 

Forgive my ignorance I am new to the TCP/IP stack scene. I am currently trying to get the LWIP stack up and running with FreeRTOS on a Microblaze based system. I have successfully started a TCP server and managed to connect a client. The test code I have hacked together simply writes a string containing an incremental count from the server to the client (15 bytes or so at 1Hz), which the client receives and then prints to the screen.

 

I am aware that the when sending data to LWIP it is under no obligation to put the data on the wire as soon as it receives it (I think that is part of the TCP protocol). It can wait a period of time to see if new data arrives so it can send it in more efficient manner. Are these statements correct ?

 

Using Wireshark, I am seeing the data packaged up into various size frames (maximum about 300 bytes). LWIP can do this for approximately 20 seconds, however, the client does not seem to be losing any data.

 

What are the parameters of the stack that govern this behaviour? Can LWIP be configured (lwipopts.h) to minimize this effect? Would this be in keeping the TCP protocol design principles?

 

I have read using the raw API tcp_output can be used to ‘flush’ the queued data. Is this recommended? I am trying to gauge whether the behaviour I am seeing is a problem or not. My previous experience with TCP (always at the application level) is that send data through the socket should produce frames almost immediately.

 

I have used the stats functionality and activated some of the debug in the TCP layers, they do not seem to be indicating there is an issue. I have checked that the timer is firing periodically at the correct tick rate and set the threads (TCP thread and the xemacif input thread) be the highest priority. There is one other thread in the test that is lower in priority and periodically outputs to the console, again 1Hz)

 

I am using LWIP version 1.4.1 and FreeRTOS 9 (both of these come packaged with the Xilinx SDK along with the drivers for the hardware).

 

A period of time into the test (after approximately after 300 messages) and begin to see re transmissions on Wireshark and the server starts to struggle sending data.

 

Any insight into any of the questions have posed would be appreciated.

 

Thanks

 

 

 


_______________________________________________
lwip-users mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/lwip-users
Reply | Threaded
Open this post in threaded view
|

Re: Socket API send command packaging up data

goldsimon@gmx.de


Am 31. Juli 2018 11:13:00 MESZ schrieb Mike Danby <[hidden email]>:

>Hello,
>
>Forgive my ignorance I am new to the TCP/IP stack scene. I am currently
>trying to get the LWIP stack up and running with FreeRTOS on a
>Microblaze based system. I have successfully started a TCP server and
>managed to connect a client. The test code I have hacked together
>simply writes a string containing an incremental count from the server
>to the client (15 bytes or so at 1Hz), which the client receives and
>then prints to the screen.
>
>I am aware that the when sending data to LWIP it is under no obligation
>to put the data on the wire as soon as it receives it (I think that is
>part of the TCP protocol). It can wait a period of time to see if new
>data arrives so it can send it in more efficient manner. Are these
>statements correct ?

Yes.

>Using Wireshark, I am seeing the data packaged up into various size
>frames (maximum about 300 bytes). LWIP can do this for approximately 20
>seconds, however, the client does not seem to be losing any data.

20 seconds is much too long. I'd expect to see some 100ms Delay. Could it be that your timers aren't running?

>What are the parameters of the stack that govern this behaviour? Can
>LWIP be configured (lwipopts.h) to minimize this effect? Would this be
>in keeping the TCP protocol design principles?
>
>I have read using the raw API tcp_output can be used to 'flush' the
>queued data. Is this recommended?

No. That doesn't necessarily work.

> I am trying to gauge whether the
>behaviour I am seeing is a problem or not. My previous experience with
>TCP (always at the application level) is that send data through the
>socket should produce frames almost immediately.

If you really want them immediately, disable nagle. But that's not standard either. If, by "almost immediately", you mean some 100ms maximum, lwip does that normally. There must be something wrong in your setup.

>I have used the stats functionality and activated some of the debug in
>the TCP layers, they do not seem to be indicating there is an issue. I
>have checked that the timer is firing periodically at the correct tick
>rate and set the threads (TCP thread and the xemacif input thread) be
>the highest priority. There is one other thread in the test that is
>lower in priority and periodically outputs to the console, again 1Hz)
>
>I am using LWIP version 1.4.1

This is really much too old. No wonder you have problems ;-)

> and FreeRTOS 9 (both of these come
>packaged with the Xilinx SDK along with the drivers for the hardware).

Check the list archive: the drivers have/had bugs.

Simon

_______________________________________________
lwip-users mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/lwip-users