UPGRADE YOUR BROWSER

We have detected your current browser version is not the latest one. Xilinx.com uses the latest web technologies to bring you the best online experience possible. Please upgrade to a Xilinx.com supported browser:Chrome, Firefox, Internet Explorer 11, Safari. Thank you!

cancel
Showing results for 
Search instead for 
Did you mean: 
Observer mike.danby
Observer
310 Views
Registered: ‎05-30-2018

Micorblaze LWIP transmission rate issue

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.  

 

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 Xilinx SDK 2017.2 with LWIP version 1.4.1 and FreeRTOS 9.

 

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, would be appreciated.

 

Thanks

0 Kudos