Open Groundation opened 6 years ago
Hi Nenad,
There are a few reasons for this behavior in full duplex, the most important of which is a lack of flow control solution. Please see the following link for a details on this in the context of the linux driver: https://www.xilinx.com/support/answers/71168.html In addition, some other workarounds can be found here: https://www.xilinx.com/support/answers/66670.html
Regards, Harini
Hi Harini,
thank you very much for your answer. I have looked at provided answers. However, we are not using Linux, but standalone Emac PS drivers (emacps_v3_7). I will try to make the patch for these drivers, but I lack of experience in writing Ethernet drivers. Is there a way for Xilinx engineers to provide appropriate patch for these drivers?
Best regards, Nenad
When Ethernet full-duplex communication is performed (especially at high rates - over 1Gb Ethernet), it is noticed that Tx side of communication becomes the dominant one and completely "kills" the Rx side. This problem is already described at [1]. Emac PS Tx handlers are much more frequent while Rx side is overflowed with "Receive over run" errors from Emac PS error handlers. We assume that the same thing is causing problem described at [2]. Investigation on this problem would be appreciated.
Thank you, Nenad
P.S. The problem was also noticed while using FreeRTOS+TCP network stack. Check at [3].
[1] - https://forums.xilinx.com/t5/Embedded-Processor-System-Design/Zynq-7000-LwIP-2-0-2-Low-RX-throughput-when-TX-is-active/m-p/870921 [2] - https://forums.xilinx.com/t5/Embedded-Processor-System-Design/LwIP-Unresponsive-Tx-path-amp-TCP-MSS-effect/m-p/880420 [3] - https://sourceforge.net/p/freertos/discussion/382005/thread/3bde8d1d/