TCP: prvTCPWindowFastRetransmit: Requeue sequence number

hannes23 wrote on Tuesday, January 30, 2018:

Hi everyone,
I use a zynq running TCP communication with heavy transfer speed, data sent to a PC with more than 80 MByte/sec.
Relatively often I see the debug message:
prvTCPWindowFastRetransmit: Requeue sequence number xxxxx < yyyyy
Could this be an indication, that any parameter should be trimmed in any way, or is this a normal situation
which occurs at heavy traffic?
By the way no error or missing a packet happens though.


heinbali01 wrote on Tuesday, January 30, 2018:

Hi Johannes, 80 MByte of TCP data per sec is indeed heavy traffic.

prvTCPWindowFastRetransmit() is the routine that checks for fast retransmission. This will take place when A, B, C have been sent, but only B and C have been acknowledged by the peer. At tha moment, the device assumes that packet ‘A’ got dropped somewhere.

By the way no error or missing a packet happens though.

Good. Neither it will affect the performance severely, because it is literally a “fast retransmission”.

If you want to avoid these retransmissions, there are several places to look:

  • Within the library: does the IP-stack every run out of Network Buffers? You may want to check uxGetMinimumFreeNetworkBuffers().
  • Within the driver: does xNetworkInterfaceOutput() ever result in a time-out? Does emacps_send_message() ever fail?
  • On the LAN: are there more participants on the LAN, could there be an overflow within a switch or a router?
  • Can you find statistics about the LAN? Collision counts?
  • Are you using any Ethernet hub?

Ps. there is an important patch to Zynq/NetworkInterface.c, around line 400:

         if( xResult > 0 )
             /* A packet was received. No need to check for the PHY status now,
             but set a timer to check it later on. */
             vTaskSetTimeOutState( &xPhyTime );
             xPhyRemTime = pdMS_TO_TICKS( PHY_LS_HIGH_CHECK_TIME_MS );
             xResult = 0;
+            /* Indicate that the Link Status is high, so that
+            xNetworkInterfaceOutput() can send packets. */
+            ulPHYLinkStatus |= niBMSR_LINK_STATUS;
         else if( xTaskCheckForTimeOut( &xPhyTime, &xPhyRemTime ) != pdFALSE )
             xStatus = ulReadMDIO( PHY_REG_01_BMSR );

This has nothing to do with the fast retransmissions. Ken Chang reported that in some cases, xNetworkInterfaceOutput() did not send packets, whereas the reception of packets was OK. The above patch will fix that problem.

Please report about your findings about the fast retransmissions.

hannes23 wrote on Tuesday, January 30, 2018:

Hi Hein,

thanks for your quick answer.
it seems, that the addition by Ken Chang solves the problem.

But first let me say, that the number of network buffers doesn’t run out. I start with 128
and it is dereased to about 50 - 60.
Is there a maximum for the parameter ipconfigNUM_NETWORK_BUFFER_DESCRIPTORS?

A little problem occured, when inserting the code-line from Ken Chang .
The compiler complained about niBMSR_LINK_STATUS. I removed the first two letters (ni)
and everything was fine.

With the addition from Ken the retransmits disappear. If I again remove the line I have again the
I tried to attach two screenshots of my debug-console which show the situation with/without the addition, but when I do so the post times out.
The communication speed is equal in both cases, about 88 MB/sec.

I appreciate your help very much, thank you.


kenchang1 wrote on Tuesday, January 30, 2018:

I am glad this fix helps, but I did not encounter the issue during heavy network traffic.
In my case it was when switching cables between ETH ports. In my case ulPHYLinkStatus was not updated when a cable was reconnected and network packets were received.
So, I am a bit suprised that you have the same issue during high traffic.


hannes23 wrote on Friday, February 02, 2018:

Sad to say, but I see the retransmissions coming back. Probably the reason could be outside on the LAN as Hein already assumed.
I will continue observing this.

Hello Everyone,
I’m also facing the same error with polarfire fpga on RISCV port.
I’m sending near 5000 KB video data from FPGA ethernet stack continiously.
in RISCV i used freeRTOS and want to read sensor data from it to client side with 100ms but then i got this error
prvTCPWindowFastRetransmit: Requeue sequence number xxxxx < yyyyy
if i read data with 1 second then i have no error.
if anyone find the solution then please guide me.
Thank you very much.