No announcement yet.

ltrx_udp_socket_send() behavior

  • Filter
  • Time
  • Show
Clear All
new posts

  • ltrx_udp_socket_send() behavior


    I often have the function ltrx_udp_socket_send() returning after more than 1 second.
    Is ltrx_udp_socket_send() blocking?
    If yes, there is no way to send "non-blocking" over UDP?
    If no, why does it take so long to return? considering it is UDP, it should return immediately.

  • #2
    Yes, it blocks until the data is sent.
    Without more details of where (in the flow), and how many bytes you are sending, I can't give much more detail.
    We need to allocate a network buffer, copy the data (up to buffer size), and send the buffer, repeat until the all the data is sinked or error.
    Yes, one second seems long - but I don't know what else is going on in your system at this point in time.
    (We know we can push more than a couple of megabits per second over UDP. So, unless all the packet buffers are consumed, or your link speed is really slow - this 'should' move faster.
    I'd strip the code for a minimum size test just looping on UDP and see how it flies... Then revisit


    • #3
      We need to send ~100 chars lines to the broadcast address on ap0 and wlan0. One line per UDP packet.
      The function ltrx_ip_socket_send() has the exact same behavior.

      I modified the "UDP_tunnel" demo to send the same string of 100 chars over and over during 10 sec to the broadcast address on the ap0 interface, just to see how fast I can go over UDP. I could reach 800 kbits/s. I don't lose data; I put an increment in each string line I transmit so that I could see if lines are missing.
      The function ltrx_udp_socket_send() still blocks for more than a second sometimes.

      Typically on 5000 lines of 100 bytes sent, most of the time ltrx_ip_socket_send() takes less than 1ms to return, but up to 10 times (10/5000 lines) it takes more time, from 2 ms to more than 1 second.

      If I put the thread to sleep for 1 ms between each send, it tends to be better.
      Same if I increase the MSS, altough each packet still contains only one line (of 100 chars).

      Any idea how to improve the process?


      • #4

        So, I would do two things.
        1. Validate that nothing is written to tlog as a hint.
        2. Disable WLAN0 and run your test only on the AP0 interface.
        It sure smells like another process is taking some of your resource or the radio is going off channel - possibly as a scan.


        • #5
          Ok, I found what is going on by using Wireshark.
          It actually comes from Google Chrome queries on the network (Google Analytics, Talk).
          I really need to take care of what is going on my network for testing my module code.

          Thank you for your help.