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.

Linux/AM5728: UDP packet drop issue

Part Number: AM5728


Tool/software: Linux

Hi everyone,

(Running latest SDK to date ti-processor-sdk-linux-am57xx-evm-03.01.00.06)

I have to use UDP for my project, and I am testing the UDP capability on AM5728 EVM.

My configuration: AM5728 directly connect to host linux PC in VM through gigabit cable. My host application sends 18kbyte and 13kbyte packets (through different ports) to EVM at 500 packet per second each. Total transmitting speed is 15.5 Mbyte/s.

The receiver side (EVM) has no problem receiving the data, except that when user input occurs (touch screen, keyboard, mouse, etc), I see an instant packet drop(s).

I also see a small number of packet drop even just launch "top" to monitor cpu usage. It drops 80-100 packets of every million packets.

Without any user input or and any other application running aside, UDP drops 1 or 2 packet of every million.

Question: 

1)  Is it expected to happen as user input event may take too much time on the system? 

2)  Will it solve the problem if I use UDP interrupt/event instead of while()?

Pseudo code on the EVM side: 

main()
{ 
while(1){               	
      
        if ((recv_len_1 = recvfrom(s1, buf1, BUFLEN_1, 0, (struct sockaddr *) &si_other_1, &slen_1)) == -1)
            die("recvfrom()");		        
	else 
	     readbuffer1();
        if ((recv_len_2 = recvfrom(s2, buf2, BUFLEN_2, 0, (struct sockaddr *) &si_other_2, &slen_2)) == -1)
            die("recvfrom()");		        
	else 
	     readbuffer2();
}

void die(char *s)
{
perror(s);
exit(1);
}

  • The Ethernet experts have been notified. They will respond here.
  • To answer your questions, yes user input can always have an effect and I don't think you need to change from the while loop yet. There is alot of background daemons that can affect the performance.  Are you using iperf for testing or just the App snippet you are showing?

    I would like to see a couple of network status results. If you could please attach a text file with the results of these commands, I am assuming that you are using eth0:

    ethtool -S eth0    

    cat /proc/net/snmp

  • Thank you for your reply.

    I only use my test application. 

    Here are the text file for those commands. Hope they help.

    cat /proc/net/snmp
    Ip: Forwarding DefaultTTL InReceives InHdrErrors InAddrErrors ForwDatagrams InUnknownProtos InDiscards InDelivers OutRequests OutDiscards OutNoRoutes ReasmTimeout ReasmReqds ReasmOKs ReasmFails FragOKs Frs
    Ip: 2 64 4077276 0 60 0 0 0 240905 86882 40 469 14810 4057318 221132 146547 85043 0 1870946
    Icmp: InMsgs InErrors InCsumErrors InDestUnreachs InTimeExcds InParmProbs InSrcQuenchs InRedirects InEchos InEchoReps InTimestamps InTimestampReps InAddrMasks InAddrMaskReps OutMsgs OutErrors OutDestUnreas
    Icmp: 433 103 0 226 0 0 0 205 2 0 0 0 0 0 315 0 313 0 0 0 0 0 2 0 0 0 0
    IcmpMsg: InType3 InType5 InType8 OutType0 OutType3
    IcmpMsg: 226 205 2 2 313
    Tcp: RtoAlgorithm RtoMin RtoMax MaxConn ActiveOpens PassiveOpens AttemptFails EstabResets CurrEstab InSegs OutSegs RetransSegs InErrs OutRsts InCsumErrors
    Tcp: 1 200 120000 -1 45 55 12 0 0 1353 1225 0 0 12 0
    Udp: InDatagrams NoPorts InErrors OutDatagrams RcvbufErrors SndbufErrors InCsumErrors IgnoredMulti
    Udp: 173239 50640 465 85346 465 0 0 14777
    UdpLite: InDatagrams NoPorts InErrors OutDatagrams RcvbufErrors SndbufErrors InCsumErrors IgnoredMulti
    UdpLite: 0 0 0 0 0 0 0 0
    root@am57xx-evm:~# 
    
    
    root@am57xx-evm:~# ethtool -S eth0
    NIC statistics:
         Good Rx Frames: 4467593
         Broadcast Rx Frames: 25060
         Multicast Rx Frames: 43441
         Pause Rx Frames: 0
         Rx CRC Errors: 0
         Rx Align/Code Errors: 2
         Oversize Rx Frames: 0
         Rx Jabbers: 0
         Undersize (Short) Rx Frames: 0
         Rx Fragments: 0
         Rx Octets: 2206433913
         Good Tx Frames: 615225
         Broadcast Tx Frames: 424
         Multicast Tx Frames: 355
         Pause Tx Frames: 0
         Deferred Tx Frames: 0
         Collisions: 0
         Single Collision Tx Frames: 0
         Multiple Collision Tx Frames: 0
         Excessive Collisions: 0
         Late Collisions: 0
         Tx Underrun: 0
         Carrier Sense Errors: 0
         Tx Octets: 907142809
         Rx + Tx 64 Octet Frames: 4148
         Rx + Tx 65-127 Octet Frames: 57398
         Rx + Tx 128-255 Octet Frames: 14492
         Rx + Tx 256-511 Octet Frames: 1853
         Rx + Tx 512-1023 Octet Frames: 227977
         Rx + Tx 1024-Up Octet Frames: 4776952
         Net Octets: 3113578360
         Rx Start of Frame Overruns: 0
         Rx Middle of Frame Overruns: 0
         Rx DMA Overruns: 0
         Rx DMA chan: head_enqueue: 1
         Rx DMA chan: tail_enqueue: 4413925
         Rx DMA chan: pad_enqueue: 0
         Rx DMA chan: misqueued: 0
         Rx DMA chan: desc_alloc_fail: 0
         Rx DMA chan: pad_alloc_fail: 0
         Rx DMA chan: runt_receive_buf: 0
         Rx DMA chan: runt_transmit_buf: 0
         Rx DMA chan: empty_dequeue: 0
         Rx DMA chan: busy_dequeue: 4400408
         Rx DMA chan: good_dequeue: 4413798
         Rx DMA chan: requeue: 0
         Rx DMA chan: teardown_dequeue: 0
         Tx DMA chan: head_enqueue: 19462
         Tx DMA chan: tail_enqueue: 595763
         Tx DMA chan: pad_enqueue: 0
         Tx DMA chan: misqueued: 1993
         Tx DMA chan: desc_alloc_fail: 0
         Tx DMA chan: pad_alloc_fail: 0
         Tx DMA chan: runt_receive_buf: 0
         Tx DMA chan: runt_transmit_buf: 674
         Tx DMA chan: empty_dequeue: 19439
         Tx DMA chan: busy_dequeue: 524031
         Tx DMA chan: good_dequeue: 615225
         Tx DMA chan: requeue: 17794
         Tx DMA chan: teardown_dequeue: 0
    

  • Thanks for posting the console logs.

    There were two things I was looking for. One is RX DMA overrun which is packets that dropped due to RX descriptor exhaustion, that is not happening here. The second is the network stack is discarding them perhaps due to a variety of causes. Usually adjusting the network stack buffering can help alleviate it. To adjust the network stack is not a driver setting but a user space setting. Below are some commands that you can try to increase the network buffer size to get you started, for your product you will have to find the right settings for your application. If this fixes the problem please mark this post as a verified answer.

    sysctl -w net.core.netdev_max_backlog=20000

    sysctl -w net.ipv4.udp_mem='17565 87380 50331648'

    sysctl net.ipv4.udp_mem

    sysctl -w net.core.rmem_max=50331648

    sysctl net.core.rmem_max

    sysctl -w net.core.rmem_default=50331648

    sysctl -w net.ipv4.route.flush=1

  • Thank you. This solution the problem. I don't see any packet drop whatsoever after changing those parameters.
  • Sorry, the packet drop issue still happen when I use the touch screen.

    It only happens after I haven't touched it for a few seconds. Only one packet drop occurs, and no more drops if I keep using the touch screen.

    I did the similar test by using iperf, got similar result. I got a single packet drop when I touch the screen.


    Do you have any idea why?