Hi Johannes, 80 MByte of TCP data per sec is indeed heavy traffic.
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
- 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,
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.