When packets are delayed, you see the video run in slow motion. In many ways, you are really seeing and hearing your network's performance. Very short network congestion conditions arise all the time, especially on WiFi with multiple clients and shared airspace, and real-time remote gameplay is about as intolerant of application to an imperfect network as you can find. I'm not even totally convinced this isn't what I'm seeing on my own network. It takes pretty extraordinary evidence to prove that it's not the network's fault when we can prove that packets are being delayed or dropped before reaching the client. We need to remember that 99.9% of the time these issues really are transient network problems that have nothing to do with Moonlight.
Handshaker steam background Pc#
Moonlight iOS and PC have totally different codebases and I haven't personally seen iOS affected myself. I'm highly suspicious of jumping to conclusions that iOS may be affected. This is consistent with the stutter observed, because we are getting a bunch of data dropped and the rest delayed significantly. In the trace I recorded, I saw recvfrom() take over 150 ms to return a single packet at one point. This confirms the issue is not our fault and lies with the network or OS network stack. The Moonlight receive thread is not being preempted during that time or anything, since it's able to run and call recvfrom() again when the first call times out. So it really appears that recvfrom() is blocking for over 100 ms without receiving a packet. Thread is waiting for event/lock with id 0xa33ba8a859006e9f. _recvfrom ← (6 other frames)Ġ0:05.386.880 The thread was made runnable by a timer expiration (handled by CPU 0's timer interrupt handler).
0 kommentar(er)
