FreeRTOS (Xilinx Zynq) Official Demo LWIP update

jeff29nj wrote on Friday, May 15, 2015:

I have the official demo working now on my HW where LWIP and FreeRTOS are included at the application layer (as opposed to the BSP). I read on the FreeRTOS site that the LWIP version is old? Is it possible for me to manually update the LWIP drivers for this demo?

The other “contributed” demo embeds LWIP and FreeRTOS at the BSP level. That allows for a newer version of LWIP, however that doesn’t give me the flexibility of easily updating FreeRTOS like I can with the official demo.

The performance of the “contributed” demo is twice that of the “official” demo, so I would really like to see if I can update the LWIP.

Any suggestions?


jeff29nj wrote on Friday, May 15, 2015:

The contributed demo mentions “The lwIP library is modified from v2.1 found in the Vivado 2014.2 tools”

I am not positive what official demo uses.

I had tried changing some of the lwipopt.h settings to match the XAPP1026 demo but maybe there are other improvements that are leading to twice as fast performace (as seen by iperf)?

rtel wrote on Saturday, May 16, 2015:

I would guess the performance difference will be because the contributed demo is using the raw interface, rather than the sockets interface. In a multithreaded application the sockets interface is much more appropriate, from a usability point of view.

I’m afraid it is very hard for us to provide detailed support for lwIP (which is why we created our own TCP stack). We provide references which we believe, to the best of our knowledge, are integrated and configured correctly - unlike many of the integrations we get asked questions about.


heinbali01 wrote on Saturday, May 16, 2015:

Hi Jeff,

In addition to what Richard commented about the raw versus socket interface:

FreeRTOS+TCP has chosen to present only one interface: the BSD sockets. In addition, it has optimisations such as “zero-copy”. The same memory used to receive a packet can be passed to the application (without copying), which will pass it to e.g. a disk driver.
( for systems with memory caching like Xilinx/Zynq, this zero-copy does not add much performance though. The caching is very smart )

I’m not very experienced with the Xilinx/lwIP library versions. But I just created a lwIP echo-server project for Zynq in my SDK 2015.1. It creates a directory ps7_cortexa9_0\libsrc\lwip141_v1_0. It doesn’t look really new:

* Copyright (c) 2001-2004 Swedish Institute of Computer Science.
* All rights reserved.

It works straight away (along with DHCP).
My first echo test had a speed of 2 x 1.2 MB, which is very slow.

Then I played a bit with these parameters:

#define TCP_SND_BUF      8192
#define TCP_MSS          1460       /* Perfect, is the highest for a LAN */
//#define TCP_WND        2048       /* is very low */
#define TCP_WND          ( 8 * TCP_MSS )  /* TCP window size of 8 segments */
#define TCP_SND_QUEUELEN ( ( 16 * TCP_SND_BUF )/ TCP_MSS )

and with a larger WND, I was able to exchange 2 x 3.5 MB /sec. Which is pretty good on a 100 Mbit LAN.

TCP_WND defines your TCP Window size, i.e. the number of bytes which the other party may send without immediately expecting an ACK.
Although Linux and Windows sockets will advertise a WND of 65536 or bigger, it does not make much sense to make TCP_WND much larger than 8 * TCP_MSS.

It is very difficult to measure performance or throughput in a general way. What kind of communication does your application have? Do you expect quick answers to short messages? Or do you send/receive many MB’s of bulk data?

as seen by iperf

The idea of iperf is to have an ‘independent measurement’ of performance. For TCP, it sends bulk data and the receiving end only has to acknowledge the reception. If that is what your application will also do, then iperf provides a good estimate.

I tend to measure and compare TCP-performance by using FTP on a RAM disk. It uses several tests:

1. Send a huge file to a RAM disk
2. Retrieve a huge file
3. Send thousands of small files
3. Retrieve thousands of small files

On a fast Zynq, I would expect to exchange a 100 small files a second, or exchange huge files at a speed of up to 10MB/sec (all measured on a 100 Mbit LAN).
On a normal CPU (with a 66 MHz CPU) I saw nett speeds of 3 MB /sec or 50 files (TCP connections) /second.

( PS. the capital ‘B’ in ‘MB’ stands for Bytes, not bits )

The other “contributed” demo embeds LWIP and FreeRTOS at the BSP level.
That allows for a newer version of LWIP, however that doesn’t give me
the flexibility of easily updating FreeRTOS like I can with the official demo.

Nobody will stop you from changing the project :slight_smile: You can take out the FreeRTOS and lwIP sources and put them anywhere you like and put them under your control.
If you are handy with Makefile you can also create a Makefile project.
Remind: you will still need a separate project for the hw, in my case: MicroZed_hw_platform. That produces ps7_init.tcl which will be sent after a Reset Entire System. See Target Setup of your Debug configuration.


jeff29nj wrote on Monday, May 18, 2015:

Thanks for the replies! Although the “contributed demo” can work in RAW mode, I am actually using it in SOCKET mode. I attempted to set all the LWIP options the same but was still seeing much better IPERF performance using the contributed demo. I will double check the LWIP options as suggested.

I may just stick with the contributed demo, but that demo seemed to be locked in to using heap3 implementation. I was hoping to use heap4 but not sure how to modify the demo to do that.