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().
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:
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