ZXC706 network operations very slow

[norume]

I'm seeing very slow response in my ZC706-based application network operations.

To try and figure out what's going on I created a new project based on the base Zynq example and then created an SDK project using the LWIP echo example.  I made no changes to the firmware or software -- everything is just as provided by Xilinx.

The application downloads and starts properly, but when I attempt to ping the board I see:

eric@FlashyBook 868> ping 192.168.1.10

PING 192.168.1.10 (192.168.1.10): 56 data bytes

64 bytes from 192.168.1.10: icmp_seq=1 ttl=255 time=1004.135 ms

64 bytes from 192.168.1.10: icmp_seq=2 ttl=255 time=0.210 ms

64 bytes from 192.168.1.10: icmp_seq=3 ttl=255 time=1003.004 ms

64 bytes from 192.168.1.10: icmp_seq=4 ttl=255 time=0.216 ms

64 bytes from 192.168.1.10: icmp_seq=5 ttl=255 time=1004.572 ms

64 bytes from 192.168.1.10: icmp_seq=6 ttl=255 time=0.231 ms

64 bytes from 192.168.1.10: icmp_seq=7 ttl=255 time=1001.487 ms

64 bytes from 192.168.1.10: icmp_seq=8 ttl=255 time=0.198 ms

64 bytes from 192.168.1.10: icmp_seq=9 ttl=255 time=1005.254 ms

64 bytes from 192.168.1.10: icmp_seq=10 ttl=255 time=0.252 ms

64 bytes from 192.168.1.10: icmp_seq=11 ttl=255 time=1003.902 ms

64 bytes from 192.168.1.10: icmp_seq=12 ttl=255 time=0.268 ms

64 bytes from 192.168.1.10: icmp_seq=13 ttl=255 time=1004.717 ms

64 bytes from 192.168.1.10: icmp_seq=14 ttl=255 time=0.275 ms

That seems weird.

It's as if the stack is only looking at the incoming packet queue once a second or so. The fact that I've seen no other reports of this on these pages leads me to believe that I've done something wrong.  I just can't tell what.

Again, this is the example system and firmware with no changes.  The network segment is completely quiet -- my laptop and the ZC706 are the only devices.

[norume]

After some poking around in the ethernet driver I discovered that the problem is that the transmitter sometimes does not respond to the START request in emacps_sgsend():

    /* Start transmit */

    { volatile int i; for (i = 0 ; i < 5 ; i++); }     <<<<===== Add this line

    XEmacPs_WriteReg((xemacpsif->emacps).Config.BaseAddress,

    XEMACPS_NWCTRL_OFFSET,

    (XEmacPs_ReadReg((xemacpsif->emacps).Config.BaseAddress,

    XEMACPS_NWCTRL_OFFSET) | XEMACPS_NWCTRL_STARTTX_MASK));

I have discovered a workaround that appears to fix the problem.  If I add the busy loop shown above the transmitter always appears to start as it should.  I'm not sure if this is because some previous flush of the buffer descriptors needs a little time to complete or if there's some other issue in the GEM transmitter -- but the problem definitely appears when the busy loop is omitted and goes away when the busy loop is present.