+TCP IPERF source

All the previous sourceforge links are 403’d, is there a place I can find the source for the iperf test for +TCP?

Hi @friesen, all the threads have been migrated from Sourceforge discussions to here. If there’s a particular thread you’re looking for, you can copy and paste the title you’ve turned up from your search engine and it will show on here.

This might be the link you’re looking for with the attachment from @htibosch : FreeRTOS+TCP data loss

Thanks, I hadn’t seen that. I was referring to zip file links in other theads.

Perhaps this could be added to the Demo source.

Can you point out which thread you’re referring to? We weren’t able to migrate attachments because of export limitations but I am happy to get the attachments for you on your behalf.

@htibosch what do you think about this suggestion?

Perhaps this could be added to the Demo source.

what do you think about this suggestion?

Well, there is a big difference in quality between the sources in de public demo code, and a utility like iperf3. The latter is just a tool that helps fine-tuning parameters set in FreeRTOSIPConfig.h.

Here you find the comfig items that I used recently on an STM32F4:

#define USE_IPERF                                   1
#define ipconfigIPERF_DOES_ECHO_UDP                 0

#define ipconfigIPERF_VERSION                       3

#define ipconfigIPERF_STACK_SIZE_IPERF_TASK         680  // or more?

#define ipconfigIPERF_TX_BUFSIZE                    ( 8 * ipconfigTCP_MSS )
#define ipconfigIPERF_TX_WINSIZE                    ( 6 )
#define ipconfigIPERF_RX_BUFSIZE                    ( 8 * ipconfigTCP_MSS )
#define ipconfigIPERF_RX_WINSIZE                    ( 6 )

/* The iperf module declares a character buffer to store its send data. */
#define ipconfigIPERF_RECV_BUFFER_SIZE              ( 2 * ipconfigTCP_MSS )

The more memory the faster, but this is only true on a fast LAN.

From a PC you can start a IPERF client, either for sending or receiving;

iperf3 -c --port 5001 --bytes 100M
iperf3 -c --port 5001 --bytes 100M -R

Just to be sure, I am attaching the latest source code:
iperf_task_v3_0d.zip (6.8 KB)

Thank you for posting that code.

Does this iperf3 port to FreeRTOS work for you ? I have checked it with some 3.x version and it seems its not parsing the control packets correctly.

I am getting TCP skip with a very large number.


Hola Pedro, please find the latest version of the iperf3 client here: iperf_task_v3_0e.zip (7.4 KB)

At the host site, you will have to install iperf3.

The UDP-testing has not been maintained, and probably it won’t work.

The TCP-testing should work well, both for receiving and sending.

If you see a problem, I would be gratefull if you can attach a PCAP file of the iperf conversation.

Hallo Hein,
Thanks so much for the quick response. This version you just me has the same behaviour I don’t know what might be happening.
This is the output from the FreeRTOS side:
vIPerfTask: created TCP server socket 3401d398 bind port 5001: 0 listen 0
Use for example:
iperf3 -c --port 5001 --bytes 100M [ -R ]
prvEMACHandlerTask: PHY LS now 1 (polled PHY)
Network buffers: 44 lowest 43
vIPerfTask: Received a connection from
TCP[ port 62486 ] recv[ 0 ] 21
Got Control Socket: rc -1: exp: ‘’ got: ‘NXL78159.1606318391.3’
TCP[ port 62486 ] recv[ 1 ] 102
TCP skipcount 842543414 xRecvResult 102
Control string: 1.3b4553432

and I called from a iperf with
iperf3 -c --port 5001 --bytes 512

C:\Users\nxf59728\Desktop>iperf3 -c --port 5001 --bytes 512
Connecting to host, port 5001

It just stops there!

I saw that to make the previous version I had (3.0d) to work I had to change lines 426 (in 3.0e) - it’s the same code - to
pxClient->ulSkipCount =
( ( ( uint32_t ) pcReadBuffer[strlen(pcReadBuffer) + 0 ] ) << 24 ) |
( ( ( uint32_t ) pcReadBuffer[strlen(pcReadBuffer) + 1 ] ) << 16 ) |
( ( ( uint32_t ) pcReadBuffer[strlen(pcReadBuffer) + 2 ] ) << 8 ) |
( ( ( uint32_t ) pcReadBuffer[strlen(pcReadBuffer) + 3 ] ) << 0 );
/* Receive a number: an amount of bytes to be skipped. */
FreeRTOS_printf( ( “TCP skipcount %u xRecvResult %d %d\n”, ( unsigned )pxClient->ulSkipCount, ( int )xRemaining , strlen(pcReadBuffer) ));
pcReadBuffer += strlen(pcReadBuffer) + 4;
xRemaining -= strlen(pcReadBuffer) + 4;
pxClient->eTCP_Status = ( eTCP_Server_Status_t ) ( ( ( int ) pxClient->eTCP_Status ) + 1 );

I noticed that (I think) the wrong number of skip over bytes are being read. With that change, I can make it work for 1 iteration,
But as I say, I don’t know too much about the protocol so I might be totally wrong on this!

— Edit
The NXLxxxxx is my PC’s name plus the epoch time and the cookie, which I think its correct for the client I am running v3.1.3. I have tried other 3.x versions and the cookie changes from that, to a stream of ASCII characters.

The second step is when it gets the JSON config part if I am not mistaken.

I am running on Windows and my FreeRTOS target is a CM7. The port of the FreeRTOS + the TCP layer is working fine and I was going to use iperf to start to tweak the performance up.

I am not able to update my config because I am a new user so it prevents me.

Thanks so much for your help,

Sorry I forgot to attached the PCAP trace.

Here goes!


iperf_debug.tar.gz (1.2 KB)

There is something strange in your PCAP file: when the iperf clients sends 37 bytes, the iperf server only receives 22 bytes.
I have never seen this happening!
The parser doesn’t get a complete message, only ‘NXL78159.1606318391.3’, which gives a parse error. The iperf server expects one long string in a single TCP message.

On what host is your iperf client running?
Maybe you can attach your FreeRTOSIPconfig.h, just to check?

I have been unable to answer since I am a new member. I think I know where the problem is: Are you expecting a 15-byte cookie after the machine name? That’s the issue I have been able to do some measurements if I skip over that cookie when a control packet is received.

What specific version of iperf3 have you used with this client?

Thanks so much,

I used the same iperf client version: 3.1.3
The problem is at a lower level. Your client sends 37 bytes, while only 22 bytes are acknowledged by the IP-stack.
The data that your client is sending is all good, the problem is lower.

Still these questions:

  • On what host is your iperf client running?

  • Maybe you can attach your FreeRTOSIPconfig.h, just to check?

  • How are the two connected? LAN, WiFi?

  • What CPU do you use at the embedded side?

  • Is there any router in between?