Announcement

Collapse
No announcement yet.

ltrx_udp_socket_send() behavior

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • MartinP
    started a topic ltrx_udp_socket_send() behavior

    ltrx_udp_socket_send() behavior

    Hello,

    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.

  • MartinP
    replied
    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.

    Leave a comment:


  • garry0427
    replied
    Udp

    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.

    Leave a comment:


  • MartinP
    replied
    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?

    Leave a comment:


  • garry0427
    replied
    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

    Leave a comment:

Working...
X