Huge UDP delay/lag with Android

I'm working on an Android application which sends/receives a high volume of UDP traffic to a Windows endpoint over a WLAN (and no, I can't use TCP).

The problem is that when I ramp up the traffic, I begin to see HUGE delays between when I call sendto (the app is written with the NDK) and when I see the packet arrive at the Windows endpoint. In the neighborhood of 10 seconds! The same thing happens in reverse too: I see huge delays between the packet being sent by the Windows endpoint and being picked up by recvfrom().

  • Changing SO_SNDBUF has no effect, so I don't think it's an issue with the application-level buffering control.
  • I've verified that the problem exists on a variety of Android devices, so I don't think it's an issue with the hardware/wireless drivers
  • Using a sniffer and correlating the timestamps, I confirmed that the delay is occurring between calling sendto() and the packet being sent from the Android device, so the buffering isn't happening in the AP or Windows endpoint
  • So at this point I'm all but out of ideas. The facts would lead me to believe that the buffering is happening on the Android OS layer, but 10 seconds of 10Mbps traffic? That seems too high to be feasible for an OS where memory footprint is such a huge concern.

    Also, if the issue is that I'm sending data too fast and overwhelming the OS, then I would expect sendto() to return ENOMEM or ENOBUFS... But there are no indications that anything is wrong on the Android application level.

    So my question is: what's causing this delay? And is there a way to mitigate it, or do I need to alter my application to have longer timeouts or some way of detecting this condition before it gets bad?


    You are sending too much.. how much are you sending? 10Mbps is definitely way too high. Bear in mind:

  • Every UDP datagram you send has an additional 28 byte header (UDP + IP over IPv4)
  • Connection link speeds are theoretical maximum limits that you will never be able to achieve
  • The Phone OS could be limiting you, Phone OS's need to conserve battery and try to minimise socket comms to do so.
  • OR

    You say your CPU is at 20%, how many cores do you have - you could be maxing out the core that is doing the sending, ie processing speed is the bottleneck.


    For people with the same problem:

    Try reusing the DatagramSocket. That solved it for me.


    I've seen reports of very similar behavior on the linux-rt list lately, which may be related.

    http://comments.gmane.org/gmane.linux.rt.user/10163

    For a several months I was haunted with spurious jitter, detected on

    UDP messages - multicast UDP messages where received on originating node without any delay, but on other nodes a delay in range of 10s of milliseconds was detected. Simply, it looked like a message was stuck in kernel before finally getting transmitted. Finally, thanks to LTTng tool, I was able to locate the problem down to this peace of code in net/sched/sch_generic.c:

    There appears to be a locking issue on transmit that causes the tx stall.

    链接地址: http://www.djcxy.com/p/75134.html

    上一篇: 散列图以及它如何在幕后工作

    下一篇: 巨大的UDP延迟/滞后与Android