cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Adventurer
Adventurer
5,406 Views
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 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.

Tags (3)
0 Kudos
Reply
1 Reply
Adventurer
Adventurer
5,243 Views
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

    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.

0 Kudos
Reply