I can feel the syncing on any server if players join. Yes on some its bigger, on others smaller, but definitely feelable across all pings.
Definitely not a connection issue. As were many connection issues issues with the cloud providers in the past anyway.
Having a more async data update for new joined players is fiddling work, but it could fix it, especially since new joined players have time to get the instance state data anyway; preparing the slots of data beforehand also allows less sync errors if the memory does not have to be completely allocated on the clients.
You do not need to send sudden large packets of data if players join, just split it up, and micro that process, since you got at least 10 seconds of a window.
It is a very common problem of fps (fast small packets) vs. mmo (dynamic sized information) protocols, but there are solutions to it, they just need knowledge of networking. And I bet a lot this is the simple case.
I know this sounds a bit confusing or like i want to sound very smart, but i think this is the problem in a nutshell, and its really just bringing my assumption to a point. After all, only the coder knows, since he has to measure where the simulation time gets exceeded, it could be aswell a problem on the server, who knows, all we feel is, a resync if a new player joins. I would not call that directly rubberbanding, since its just one setback per join, while rubberbanding usually is an ongoing issue, and it is also hard to say, why there is a resync without knowing the code, maybe it is triggered as part of the join, maybe the clients desync, or maybe the server instance desyncs as it gets the new players connections, and it could be as simple as rerendering something or loading resources takes too much time causing clients to request a resync, in short: the more important measurements should be done server side / from debug.
On the other note, the syncing still works well, which is a plus, it could be worse.
