TCP Receive Throughput Drops Significantly

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

cross mob
MoNo_2793136
Level 2
Level 2

We are experiencing the TCP receive throughput drop in our system. Our system uses  the TCP protocol over the Wi-Fi traffic from the Android (version 9)  to the WICED (MurataType1LD)  and on the reverse direction (WICED to Android) it uses the UDP protocol. The TCP bandwidth deteriorates when there is UDP traffic on the reverse direction. The OTA Sniffer capture file shows that the TCP is experiencing spurious or fast retransmissions on the Wi-Fi traffic from the Android to the WICED (MurataType1LD). These types of retransmissions is an indication of missing ACK or an ACK that was received  after the retransmission timer expired.  It appears that the presence of the UDP traffic on the reverse direction is delaying or interfering with the TCP protocol’s ACK transmissions. The presence of the UDP traffic on the reverse channel is hindering the transmission of the TCP’s ACK packets.

Is there any way that we can control the transmission of the TCP ACK from the WICED API?  Is there any way that another interface(s) can be exposed to the WICED API to expedite the transmission of the TCP ACK?  What other interfaces from the WICED API can be used to improve the TCP throughput?

Thanks, Mohammad

0 Likes
8 Replies
Zhengbao_Zhang
Moderator
Moderator
Moderator
250 sign-ins First comment on KBA 10 questions asked

Hello:

Are you using 43438 in wiced for the test ?

0 Likes

Yes.  He mentions this in his initial post and again here in this one: https://community.cypress.com/message/212680?et=watches.email.thread#212680

0 Likes

The platform that I using is Murata Type1 LD.

0 Likes

Hello:

Our system uses  the TCP protocol over the Wi-Fi traffic from the Android (version 9)  to the WICED (MurataType1LD)  and on the reverse direction (WICED to Android) it uses the UDP protocol .

From descriptions,  you are using TCP and UDP running together .

Android --> Wiced   TCP  ,   in the mean time,  there has a ACK from wiced --> Android.

Wiced -->  Android  UDP  .

Now we can see two streams are from Wiced  to Android,  one is ack  , the other is UDP.

Did you try to limit the UDP bandwidth when doing the test ?  or disable UDP  test first to see if the UDP stream has an influence.

Yes, I have tried disabling the UDP transmission on the reverse link, in that configuration, the TCP throughput does not drop and the retransmission happens rarely. Without the UDP traffic on the reverse link there is no problem with the TCP throughput. The TCP throughput drop happens when there is UDP traffic on the reverse link. The UDP traffic on the reverse link is about 2 Kilo Bytes per second and the TCP traffic should be around 200 kilo Bytes per second. So, the UDP traffic load is much lower than the TCP traffic.

Thanks, Mohammad

0 Likes

I think your UDP thread should occupy the mcu for a long time when concurrent with TCP.

You can have a check about that ,   IIt is better you can create two threads one is for tcp , one is for udp .

Have a system time print to calculate the occupied time for every UDP packet transfer , then sleep the thread , give mcu back to TCP thread.

The TCP reception and UDP transmission were always in separate threads. I have already checked the CPU occupancy time of each thread through the scope using GPIO pins. The occupancy of the UDP transmission is less than 1 milliseconds and the TCP thread occupancy is about 7 milliseconds. The UDP thread is sleeping on a semaphore that is set by the SPI interrupt. The UDP thread runs when there is data from the SPI. The frequency that the SPI receives data is about 128 bytes per 200 milliseconds. Given the SPI data reception rate, The UDP is transmitting about 1 kilo bytes per second. The UDP thread’s usage of the CP is a small fraction of the time that the TCP thread uses. As I indicated in one of my last postings that UDP transmission load is small fraction of the TCP reception load. So, given the occupancy timing of the threads and the loads they are handling, the TCP thread is getting the CPU time that it needs. It has been verified that the TCP thread is receiving sufficient CPU time.

Thanks, Mohammad

0 Likes

That is strange, I will try to duplicate the environment of your TCP , UDP running together , but it really need some time .

0 Likes