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
. 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.
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
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
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 🙂 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:
. That produces
which will be sent after a
Reset Entire System
of your Debug configuration.