Why is the iperf tcp speed different than the TCP_CLIENT example in WICED?

Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
HaSo_2959646
Level 2
Level 2
First like received First like given

Hi all,

When I am testing the maximum tcp speed through the iperf example in WICED, for 5 GHz (80 Mhz bandwidth), it gives me around 75 Mbps, however the TCP_CLEINT example is way slower than that and it barely reaches to 2 Mbps. I tried to remove the echo back from the server and reduce the delay time between each transmission and also increase the length of "tx_data" but when it is more than 1500 characters, the module resets multiple times during the tcp connection and does not start the communication.

By the way, I don't see any speed difference when I'm changing the TCP_PACKET_MAX_DATA_LENGTH which is strange. In the iperf example, by increasing the tcp window size up to a certain point, the speed also increases which it makes sense. In the TCP_CLEINT example, the packet length can't go above 65535 characters which I guess there is no such a limit in the iperf example...

Is there any benchmark on the tcp_client example? How to push up the speed to 75 Mbps in the TCP_CLIENT example? I need to repeat the iperf speed results on my own data through the tcp connection!

Kind regards,

Hamid.

0 Likes
1 Solution

The TCP library APIs have currently limited their data transmission capability to MTU size which is 1500 bytes. We have made enhancements in the library to enable the TCP stream APIs to send and receive payload greater than MTU size. This is expected to be available in WICED Studio 6.1.

View solution in original post

20 Replies
HaSo_2959646
Level 2
Level 2
First like received First like given

Can anyone assist me with this please?

0 Likes

Adding the Level 1 applications team.

grsr lsri rash mady gsns ankh,wwfe

0 Likes
AxLi_1746341
Level 7
Level 7
10 comments on KBA 5 comments on KBA First comment on KBA

hsoleimani_2959646 wrote:

By the way, I don't see any speed difference when I'm changing the TCP_PACKET_MAX_DATA_LENGTH which is strange. In

Because TCP_PACKET_MAX_DATA_LENGTH is not used at all.

It is used when creating the packet through this function: wiced_packet_create_tcp!

Is there is anyone here to give me a solid answer on the question?

0 Likes

hsoleimani_2959646 wrote:

It is used when creating the packet through this function: wiced_packet_create_tcp!

Is there is anyone here to give me a solid answer on the question?

Take a look at the implementation of wiced_packet_create_tcp(), you will find it is not used at all.

0 Likes

Thanks but this is not all my question about. Can you assist me with other parts of the question? How to improve the throughput of the TCP_CLIENT code and make it close to the Iperf example in terms of speed?

0 Likes

hsoleimani_2959646 wrote:

Thanks but this is not all my question about. Can you assist me with other parts of the question? How to improve the throughput of the TCP_CLIENT code and make it close to the Iperf example in terms of speed?

Despite of the terms of speed.

You clearly reported a bug of the SDK because the module resets multiple times during the tcp connection and does not start the communication. And that needs to be fixed first.

axel.lin_1746341 Ture! When the size of the TCP packet is more than 1500 characters, the chip resets when connecting to the server. Based my previous experiments, the more data you can send out in one iteration (the larger TCP packet size), the higher throughput is achieved, however in the TCP client application there is a limitation on that...

0 Likes

The TCP library APIs have currently limited their data transmission capability to MTU size which is 1500 bytes. We have made enhancements in the library to enable the TCP stream APIs to send and receive payload greater than MTU size. This is expected to be available in WICED Studio 6.1.

When will WICED Studio 6.1. be released?

hsoleimani_2959646 wrote:

When will WICED Studio 6.1. be released?

grsr

I have the same question.

From the forum, I can find the FAE mentions upcoming release since Dec. of 2017.

It took so long for waiting for the new release.

0 Likes

We are close to a release but we cannot give you an exact date because there are still some tests running. Regarding the throughput numbers, we test the throughput on iperf, not on snip.tcp_client.

0 Likes

grsr wrote:

The TCP library APIs have currently limited their data transmission capability to MTU size which is 1500 bytes. We have made enhancements in the library to enable the TCP stream APIs to send and receive payload greater than MTU size. This is expected to be available in WICED Studio 6.1.

So do you have the throughput improvement number for newer SDK?

0 Likes

We have just received and tested the new CYW954907 dev board with IEEE ac protocol and achieved a remarkable speed of 150 Mbps (TCP) and 200 Mbps with Iperf. Great job!!

However, the limiting factor for our project is still the MTU size which is 1500 Bytes, therefore, the TCP example is limited to ~20 Mbps. Hopefully this will be solved in WICED SDK 6.1.

grsrmifolsriankhgpeyton_2923021

0 Likes

grsr wrote:

The TCP library APIs have currently limited their data transmission capability to MTU size which is 1500 bytes. We have made enhancements in the library to enable the TCP stream APIs to send and receive payload greater than MTU size. This is expected to be available in WICED Studio 6.1.

grsr

Can you provide some example or documentation about "enable the TCP stream APIs" in sdk-6.1?

Thanks.

0 Likes

alberto.girolami2_2862441 wrote:

Any news?

Thanks.

I guess you are asking grsr , not me.

I don't get any follow up response.

0 Likes

wwfe​ is working with the SW team/ dharam on a response and someone from his team will provide the official answer.

Based on my understanding of the internal dialog, the TCP client application is a very basic application where you simply open a socket ,send the data, receive a response and disconnect; this will then repeat every 2 seconds. In contrast, It's my understanding that iperf will perform the data transfer in a single connection.

Essentially, the objective of the TCP client application is not really for performance measurement, but to demonstrate how to both use the WICED TCP client & how to communicate with a TCP server.

Again, we believe that the iperf client will send data over single connection, and the implementation will be more robust then our TCP client application.

grsr lsri rash mady gsns ankh

Thanks mifo for the response! What do you mean by a single connection? Does that mean Iperf opens up a socket and sends data continuously and measures the speed and then closes the connection once?

I understand that the TCP client application is a basic program, but I have tried to make it faster as much as possible by removing the echo response, delay and unnecessary prints and conditions. However, it reaches almost half the speed of the Iperf application.

I need to transfer my own data with the speed of Iperf example (~75 Mbps). As the Iperf example is only used for throughput measurement and can reach a high speed on the hardware, I think there must be a way to boost the TCP client example which is using the same hardware. This looks like a software issue. Is there such an application in WICED?

0 Likes

Per your initial question, my understanding is aligned with yours. 

I'm not sure if anyone internally has tried to optimize the performance of the TCP Client App, but I'm hoping that the Level 1 team I added to the discussion can check with the SW team to see if they can provide guidance.