Showing results for 
Show  only  | Search instead for 
Did you mean: 
Registered: ‎04-01-2015

ZXC706 network operations very slow

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

PING ( 56 data bytes

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

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

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

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

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

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

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

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

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

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

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

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

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

64 bytes from 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.

Tags (3)
0 Kudos
1 Reply
Registered: ‎04-01-2015

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






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.

0 Kudos