• State
  • Locked Locked
  • Replies 2 replies
  • Subscribers 98 subscribers
  • Views 458 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

DM8169 udp network TX packet loss

James Michael
Prodigy 60 points

Hello,


I am using Z3s dm8169 RPS module and have discovered a problem with UDP tx.

I am testing udp packet performance using iperf (server on a known good pc, known good network, client on DM8169).

The device appears to have 2 states:

    The "good" state has zero udp TX packet loss well above 200mbps

     The "bad" state has zero udp TX packet loss upto 20mbps, but progressively worse loss above that

I have not found a pattern for getting into or out of these states yet.

I verified that eth0 is in 1000Mbps mode in both states (using ethtool). 

The packets that are dropped in the bad state do NOT show up as dropped packets on dm8169 /proc/net outputs.  These show that all packets are good.

The iperf server and network has been verified by other sources as good.

Is there a way to dump all the settings for the EMACs to see what is different in these two states?  Any other places I should be looking?

  • 0
    TI__Guru 59700 points

    Are you seeing the same number of bytes transfer per  minute in the good and bad case.

    Executing ifconfig and  checking delta in bytes transmitted can be used.

    To print the emac regs you can refer function emac_dump_regs in

    \linux-dvr-rdk\drivers\net\davinci_emac.c

    You can probably add call to emac_dump_regs in function emac_dev_getnetstats so that querying net stats will also print the registers.

    Do you have visibility on the number of bytes received by the RX side. Running iftop  on receiver would show bytes received from specific port.

  • 0 in reply to Badri Narayanan
    Prodigy 60 points

    This problem is resolved.  It was caused by a runaway AJAX routine on a web page presumably flooding netra with http requests.  Removing ajax eliminated the "bad" state.