STEAM GROUP
Steam Remote Play homestream
STEAM GROUP
Steam Remote Play homestream
2,455
IN-GAME
32,818
ONLINE
Founded
November 7, 2013
Bisecting Steam Remote Play Together Packet Loss / Jitter
Summary: two of my friends and I are trying to play Tales of Vesperia through Remote Play Together, however recently we've had issues where the video will intermittently drop 99% of frames for a while, then return to normal when there's nothing on screen. I think it's due to packet jitter on a (non-Steam) network backbone between the host and the two clients, but I'm unsure of how to troubleshoot this using the tools available in Steam and the streaming client, or with additional third-party tools.

---

For the past few months, a few friends and I have been trying to do a playthrough of Tales of Vesperia using Remote Play Together. It's worked decently well for the most part (though currently non-Steam controllers don't appear to work properly for remote clients - but that's another thread), however over the past 2-3 weeks we've been having issues where the video stream suddenly becomes highly intermittent (advanced stats show that 99%+ of video frames are being dropped), making the game unplayable during these periods. The video issues tend to persist until either a loading screen is reached (which is essentially all-black with a small icon), or if some other simple screen is shown for a second or two (I assume that during this time, the required video bandwidth drops enough that the bandwidth and timing requirements to show the frame are reduced). In addition to the game video/audio lockups during these spikes, there are two other important observations we've made:

1. Based on the advanced streaming stats, packet loss increases to somewhere between 20-40% during these events (note that it doesn't tend to fluctuate between these bounds, but stay around a specific value, like 30% or 25%)

2. We use a non-Steam voicechat server (Mumble) that I host on my home server, and during the described events the host's voice quality is reduced to the point where they are near unintelligible. Packet loss reported by the Mumble server also increases significantly.

We have tried a whole bunch of things to try and mitigate the issues, but so far nothing we've done has eliminated or reduced the severity of these lag spikes. Here's a semi-complete list of things we've tried:

1. Host reducing game resolution to 900p
2. Clients reducing resolution to 900p
3. Clients reducing streaming bandwidth to 3Mbps (Host has a 5Mbps upload speed)
4. Enabling/Disabling Remote Play port forwards on the host's router

One thing that we've been coming back to is the possibility that there is a backbone network issue, either on Steam's end or on our ISP's / intermediary connections' end. We all have the same ISP; the host is on the east coast, I am in the midwest, and the other client is out west. When running a combination traceroute/ping (mtr), I found that in the link between me and the host, there is an ISP backbone connection in Boston that exhibits extremely high packet jitter (60-80ms during long tests).

My running theory is that the high jitter on the hop through Boston is causing the packets to either arrive in the incorrect order, or otherwise be discarded as lost by the streaming clients, however at this point I have no idea what else I can try to validate or invalidate this theory. There are of course other possibilities, such as the bandwidth required to stream by the host intermittently exceeding available upload bandwidth (which would make sense given the voicechat dropouts), or a misconfiguration on one of the clients or their networks, or even a network issue on Steam's end. However, I have thus far been unable to come up with any ways to further bisect this issue.

If anyone has any ideas on tools to use to troubleshoot the connection, or settings in the Steam client that could potentially alleviate issues, I'm willing to try them.
< >
Showing 1-3 of 3 comments
I did some more troubleshooting today, and I think I have a new theory as to what's going on.

As I mentioned in the OP, at one point in time the host was able to stream to two clients without a problem, however recently the connection has been problematic. Today I had the host check their bandwidth usage when one / both of us were connected; when only one of us was connected, the client only used 3-6 Mbps, but when both of us connected they were using 10+ Mbps. This was measured on the host's computer, and the host's ISP limits upstream bandwidth to 5 Mbps.

I am going to try and use the Steam console to manually limit the bandwidth use for each client such that we don't saturate the host's upstream bandwidth, but it seems as though Steam could do one of two things (if not both) to alleviate this issue:

1. Better detection of bandwidth saturation to better throttle the video stream. My (new) current theory is that bufferbloat on the host's router is causing packets to get delayed but not dropped, which results in a video stream that always gets behind and never recovers until the buffer gets cleared (typically during calmer / blank screens that result in a smaller stream temporarily). In the background, the streaming clients should be able to inform the host that incoming packets are getting dropped or are delayed, which should result in the host limiting stream bandwidth to reduce latency.

2. Always route the first hop from the host through the same Steam network node so that the video stream can be forked on the Steam network side, instead of having the host potentially use 2x the bandwidth for the same video stream to two different clients. This would allow the host to use their full upstream bandwidth and not have to worry about how many clients connect.
dave Aug 15, 2021 @ 3:07pm 
Not got a fix but have found the same thing. Did you get it working more consistently with any tweaks within Steam settings for client or host?
Maluszek89 Jun 21, 2022 @ 2:59pm 
2022 june and i still have same problem. both 60/20 upload/ downolad/
< >
Showing 1-3 of 3 comments
Per page: 1530 50

Date Posted: Apr 11, 2020 @ 6:57pm
Posts: 3