Quality RTOS & Embedded Software

 Real time embedded FreeRTOS RSS feed 
Quick Start Supported MCUs PDF Books Trace Tools Ecosystem


TCP: prvTCPWindowFastRetransmit: Requeue sequence number

Posted by hannes23 on 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.


TCP: prvTCPWindowFastRetransmit: Requeue sequence number

Posted by heinbali01 on 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 = pdMSTOTICKS( PHYLSHIGHCHECKTIME_MS ); xResult = 0; + / Indicate that the Link Status is high, so that + xNetworkInterfaceOutput() can send packets. */ + ulPHYLinkStatus |= niBMSRLINKSTATUS; } else if( xTaskCheckForTimeOut( &xPhyTime, &xPhyRemTime ) != pdFALSE ) { xStatus = ulReadMDIO( PHYREG01_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.

TCP: prvTCPWindowFastRetransmit: Requeue sequence number

Posted by hannes23 on 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 ipconfigNUMNETWORKBUFFER_DESCRIPTORS?

A little problem occured, when inserting the code-line from Ken Chang . The compiler complained about niBMSRLINKSTATUS. 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 'problem'. 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.


TCP: prvTCPWindowFastRetransmit: Requeue sequence number

Posted by kenchang1 on 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.

regards, Ken

TCP: prvTCPWindowFastRetransmit: Requeue sequence number

Posted by hannes23 on February 2, 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.

[ Back to the top ]    [ About FreeRTOS ]    [ Privacy ]    [ Sitemap ]    [ ]

Copyright (C) Amazon Web Services, Inc. or its affiliates. All rights reserved.

Latest News

NXP tweet showing LPC5500 (ARMv8-M Cortex-M33) running FreeRTOS.

Meet Richard Barry and learn about running FreeRTOS on RISC-V at FOSDEM 2019

Version 10.1.1 of the FreeRTOS kernel is available for immediate download. MIT licensed.

View a recording of the "OTA Update Security and Reliability" webinar, presented by TI and AWS.


FreeRTOS and other embedded software careers at AWS.

FreeRTOS Partners

ARM Connected RTOS partner for all ARM microcontroller cores

Espressif ESP32

IAR Partner

Microchip Premier RTOS Partner

RTOS partner of NXP for all NXP ARM microcontrollers


STMicro RTOS partner supporting ARM7, ARM Cortex-M3, ARM Cortex-M4 and ARM Cortex-M0

Texas Instruments MCU Developer Network RTOS partner for ARM and MSP430 microcontrollers

OpenRTOS and SafeRTOS

Xilinx Microblaze and Zynq partner