Multiplayer Pausing Issues
-
I’m running BMS 4.33 x64 Korea Campaign (Iron Fortress) and it’s almost like every 20-30 minutes we get a server pause with this error about time compression ratio. I haven’t been able to find any information on why this is doing this.
Host UP speed set to 10000 (10mbps), all clients using 1024.
-
Most likely explanation is that the server to client connections are periodically slowing down…a lot. To a first approximation what that message means is that the network pipe isn’t big enough to carry the data to send at the present time. To fix it you need more consistently wide open network pipes. Try and get rid of obvious culprits (like not using WiFi anywhere in the mix)…that might help.
-
How many upload has the server available on his internet connection?
Campaign or TE?
-
Campaign.
The server is on a dedicated 20mbps upload pipe. No other computer is connected to that pipe.
What would be a good connection bandwidth setting for the server if you are running a campaign and have 20mbps upload speed? We tried with 2500 instead of 10000 and it didn’t make any difference.
-
If you have so many upload available then give it to the server. Set it to 19000 so have a bit overhead for speed fluctuations.
How many clients?
-
Rated pipe capacity may not be the issue. From the symptoms it seems like the pipe is narrowing substantially between it and one or more clients, but not all the time. Something in the network is the most likely place to look but it is possible that throughput is constrained because something on one or other machine slows down enough that network packet processing is impacted. The code does everything we could think of to try and mitigate fluctuations in network performance but in the end “bad” pipes will deliver this kind of symptom.
-
Rated pipe capacity may not be the issue. From the symptoms it seems like the pipe is narrowing substantially between it and one or more clients, but not all the time. Something in the network is the most likely place to look but it is possible that throughput is constrained because something on one or other machine slows down enough that network packet processing is impacted. The code does everything we could think of to try and mitigate fluctuations in network performance but in the end “bad” pipes will deliver this kind of symptom.
Makes sense. I’m a programmer too and know all too well the woes (and benefits) of UDP. If it’s truely just the internet that’s the culprit (packet loss due to transit) than I wonder what would happen if we piped our connections through a direct VPN or something. I’m wondering if then would we see the same issue. UDP packets would be sent to the VPN IP, the VPN would translate them direct to the client’s IP via TCP/IP. It might possibly slow it down some but you would have a guaranteed delivery.
In the future, would it be at all possible to have the time sync and related data on a TCP pipe while matrix updates of positions are on UDP?
-
While the traffic is all UDP at present, we do use reliable extensions over and above raw UDP for traffic that has this kind of sensitivity; timing sync is the obvious poster child. Using TCP for that turns out to work less well.
There’s also plenty of unreliable traffic: position updates are sent unreliable but timestamped…obviously ones that arrive out of order can thus be simply discarded.
In the limit VPN and TCP won’t fix a “bad” quality pipe unfortunately when it comes to time-sensitive content transmission…if not enough stuff is getting through per time quantum it doesn’t matter how many protocol layers and tricks you play…the bits just aren’t getting from A to B.
-
I should perhaps add that “reliability” in the sense I mean here has multiple priority levels for what goes through the pipe in which order as well. Again, we’re trying to do everything we can think of to eliminate the network transport vagaries that plague the internet when it comes to latency-sensitive, interactive gaming experiences but there’s a limit to what we can do without resorting to telling everyone “get on the same LAN segment!”.
-