CC3235MODASF: 400ms delay for TCP retrasmittion

Mauro Fantina

Genius 3800 points

Part Number: CC3235MODASF
Other Parts Discussed in Thread: UNIFLASH, SIMPLELINK-CC32XX-SDK

Hello.

I've developed a TCP firmware for SimpleLink.

The firmware configure SimpleLink as WiFi direct client and DHCP addressing.

I have developed a UWP c# software for my Windows 10 PC.

The software connects to SimpleLink using WiFi Direct (configure PC as GroupOwner).

After established connection the SimpleLink Listens on a TCP socket.

The PC connects to this TCP socket.

After TCP accepts incoming PC connection, the SimpleLink transmits packets wide 1kByte at maximum rate (I have a continuous loop that calls sl_Send continuously).

Sometimes I observe 1..2...3 seconds of delay between PC's "socket.receive" calls.

I use WireShark to inspect what's the matter.

The problem is that sometimes (due to noise in my environment: I'm in a factory with inverters)

some packets are lost and Windows 10 send Dup ACK (duplcated ACK) to inform SimpleLink about his loss.

See image.

SimpleLink retransmits this lost packets ---> OK !!

But I observe that SimpleLink retransmits lost packet 400ms after ACK : this is a problem for my aplication !! See image below.

192.168.137.214 is SimpleLink.

192.168.137.1 is my PC.

This 400ms delay is configurable ? I wish it was under 10ms...

Can someone help me ?

over 4 years ago

0 Vincent Rodriguez over 4 years ago

TI__Mastermind 28285 points

Hi Mauro,

What service pack are you using? Unfortunately no, this is not configurable and have to do with the implementation of our fast retry mechanism in the TCP stack. in newer SPs, we made a fix that made this more responsive.

BR,

Vince

0 Mauro Fantina over 4 years ago in reply to Vincent Rodriguez

Genius 3800 points

How much time with the new fast implementation?

Months?

0 Vincent Rodriguez over 4 years ago in reply to Mauro Fantina

TI__Mastermind 28285 points

It should trigger after the third duplicate Ack. What SP are you using?

BR,

Vince

0 Mauro Fantina over 4 years ago in reply to Vincent Rodriguez

Genius 3800 points

I realize that I'm using SDK 4.10.00.07

But I have installed also 4.20.00.07 ... it is sufficient to change COM_TI_SIMPLELINK_CC32XX_SDK_INSTALL_DIR to upgrade at 4.20.00.07 ?

For the new fast retry mechanism implementation how long I have to wait ? Our company director plans six months time to market for this product ...

Is it possible to have a beta version to do some test in out laboratory for the prototipe ?

It should trigger after the third duplicate Ack. ====> No , I see retrasmittion after #19 ... see the second image in the first post

0 Vincent Rodriguez over 4 years ago in reply to Mauro Fantina

TI__Mastermind 28285 points

Hi Mauro,

You will need to flash the service pack. This is a file in the SDK that adds bug fixes/enhancements to our device. Please review here for more info - https://dev.ti.com/tirex/explore/node?node=ABEoqU9o3snoxDcmIpW0EA__fc2e6sr__LATEST

BR,

Vince

0 Mauro Fantina over 4 years ago in reply to Vincent Rodriguez

Genius 3800 points

Ok, but about "fast retrasmittion mechanism"

when the new SP is scheduled?

0 Vincent Rodriguez over 4 years ago in reply to Mauro Fantina

TI__Mastermind 28285 points

Hi Mauro,

These fixes were already intregrated into the SP, early 2020. So if you grab the latest SP, you should see an improvement.

BR,

Vince

0 Mauro Fantina over 4 years ago in reply to Vincent Rodriguez

Genius 3800 points

Ok, I misunderstand,

tomorrow morning I'll do some tests..

I hope this will resolve my problem

0 Mauro Fantina over 4 years ago in reply to Mauro Fantina

Genius 3800 points

Hello.

This morning I update NWP Service Pack File with UNIFLASH at

SIMPLELINK-CC32XX-SDK_4.30.00.06

Release Date: 02 Oct 2020

downloaded from https://www.ti.com/tool/download/SIMPLELINK-CC32XX-SDK

I start my tests but I observe 100ms ...400ms delay between packets.

I capture a situation where I observe this delay.

I see that PC recognizes TCP segment not captured and starts TCP Duplicated ACKs.

I see that SimpleLink responds with TCP fast retransmission after #26 duplicated ACKs. Why not after #3 duplicated ACKs ?

0 Vincent Rodriguez over 4 years ago in reply to Mauro Fantina

TI__Mastermind 28285 points

Hi Mauro,

Just to make sure I understand, the delay is now 100ms? Why it doesn't send the packet immediately has to do with our internal TCP stack implementation, and how we are handling the fast retransmission mechanism. There isn't a way to improve this further.

BR,

Vince

0 Mauro Fantina over 4 years ago in reply to Vincent Rodriguez

Genius 3800 points

In the previous capture the PC doesn't receive two consecutive packets.

PC starts to transmit DUP ACKS and simple link retransmit the first lost packet after 100ms, but the second after 400ms

0 Vincent Rodriguez over 4 years ago in reply to Mauro Fantina

TI__Mastermind 28285 points

Hi Mauro,

I think that makes sense. the first is the TCP Fast retransmit @ 100ms. The second would be our default TCP retry timeout of 400ms. We will only send one TCP Fast Retry, and if this fails for whatever reason, you will be governed by the TCP retry timeout at 400ms.

BR,

Vince

0 Mauro Fantina over 4 years ago in reply to Vincent Rodriguez

Genius 3800 points

Ok...but see this problems with TCP in our development group we are moving to use UDP and try to implement ACK mechanism in application layer.

I have a suggestion/proposal:

why don't provide a way to enable 10ms retrasmisttion timer for TCP ?

For example

SlSockTcpUltrafast_t enableOption;
enableOption.IsUltrafastEnabled = 1;

sl_SetSockOpt(Sd, SL_SOL_SOCKET, SL_SO_ULTRAFAST, (_u8*)&enableOption,sizeof(enableOption));

0 Vincent Rodriguez over 4 years ago in reply to Mauro Fantina

TI__Mastermind 28285 points

Hi Mauro,

This has to deal with our implementation of the TCP stack, and this is not currently available. I will report this as a feature request to R&D.

BR,

Vince

0 Mauro Fantina over 4 years ago in reply to Vincent Rodriguez

Genius 3800 points

OK, tell me what will the answer

Wi-Fi

Wi-Fi forum

CC3235MODASF: 400ms delay for TCP retrasmittion