TCP: prvTCPWindowFastRetransmit: Requeue sequence number

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. Greetings.

TCP: prvTCPWindowFastRetransmit: Requeue sequence number

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.

TCP: prvTCPWindowFastRetransmit: Requeue sequence number

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. Johannes

TCP: prvTCPWindowFastRetransmit: Requeue sequence number

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

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.