5 bars - the player should be able to play at TR 16 on low latency
4 bars - the player should be able to play at TR 12 on low latency
3 bars - the player should be able to play at TR 10 on high latency
2 bars - the player should be able to play at TR 8 on extra high latency
1 bar - the player cannot play at any TR on any latency

5 bars - high confidence that this player can play at selected TR on low latency
4 bars - the player should be able to play at selected TR on low latency
3 bars - the player should be able to play at selected TR on high latency
2 bars - the player should be able to play at selected TR on extra high latency
1 bar - the player is unlikely to be able to play at selected TR, or has no connectivity to you

Historically there have also been "conflicts" between certain players that disallow them to play together with certain hosts without lag

To elaborate on this, what everyone in a game experiences is cripplingly grinding lag, where the game will run for a fraction of a second, followed by a pause of about 1 second, then more action etc.

The conflict appears to be some sort of IP adressing conflict between a pair of players in the game; unfortunately I don't know the specifics of what the conflict is, but it may be something like two players using ISPs that are doing some sort of carrier-grade NAT. It is also likely to be influenced by whether all players have open or closed TCP networking ports for StarCraft.

Although the precise cause is unclear, the symptom very much looks like player A is incorrectly receiving the game data packets intended for player B from at least one other player in the game, and so player A forwards the packets on to player B, thus doubling player B's effective latency, and because StarCraft requires everyone to be in sync, everyone suffers.

If either player A or B leave the game, the lag disappears. Players often associate this form of lag with whomever leaves the game first that alleviates the lag as being "the lagger", but it is actually the pair of players that is the problem. Especially degenerate cases may exist where there are three players affected, or two separate pairs of players.

I am not sure whether this type of lag still occurs in SCR or not.

[quote=name:jjf28]
I am not sure whether this type of lag still occurs in SCR or not.

It's unfortunate that the vast, vast majority of players on Battle.net do not even know what this forum is, let alone would actually read the post.. it would go a long way toward resolving the problem, though.

Hi all,

In our ongoing efforts to combat latency in SCR, we've revamped the custom games latency bar system to make it more meaningful for players.

First, it's important to distinguish between the latency bars displayed on the game search screen vs the latency bars in the game lobby. In the game search screen, the latency bars are based on geodistance (the distance from you to the advertised game host) and therefore are very approximate. We do not show actual latency here because it would involve a lot of packets being sent to hosts and back, and would be somewhat akin to DDOSing the host.

In the game lobby screen, we do show actual latency. We've revamped the system in 1.21.3. Now, the latency bars depend on which turn rate the host has selected. The meaning remains the same regardless of turn rate:

5 bars - high confidence that this player can play at selected TR on low latency
4 bars - the player should be able to play at selected TR on low latency
3 bars - the player should be able to play at selected TR on high latency
2 bars - the player should be able to play at selected TR on extra high latency
1 bar - the player is unlikely to be able to play at selected TR, or has no connectivity to you

In 1.21.3, we have also rolled out our Dynamic Turn Rate system for custom games as an option. The meaning of the bars in this case are:

5 bars - the player should be able to play at TR 16 on low latency
4 bars - the player should be able to play at TR 12 on low latency
3 bars - the player should be able to play at TR 10 on high latency
2 bars - the player should be able to play at TR 8 on extra high latency
1 bar - the player cannot play at any TR on any latency

It's also worth remembering that latency is a moving target - ping times can change (sometimes dramatically) during the course of a game (or even while in the lobby), which means these bars are a guide only. There's no guarantee that a player will maintain their current connection - it could get better or worse with time.

Finally, and importantly, the current latency bar system only measures latency between you and the other player. StarCraft uses a networking algorithm that is optimal when all players have good connectivity to all other players. Therefore, it's incumbent on all players to make it known to the host if they have particularly poor connectivity to another player. In future we'd like to investigate elevating all latency times to the host so that the host can be properly informed.

I spoke with Tec to get a little more data behind the numbers and to answer some of the questions here.

First, what does "turn rate" really mean? "Turn rate" is frequency of updates per second. TR8 would mean 8 updates per second (125ms per update), TR16 would mean 16 updates per second (62.5ms per update). For reference, the game processes 24 updates per second on Fastest game speed. If you were to look at it visually, it would look like this:



Now, let's say you issue a command X somewhere along that timeline. The distance between the X and the next | determines how long it takes for your command to get sent to the other players. And for the command to get executed, it has to take another full turn so that it can come back to you as validated by the other players in the game.

If any player in the game does not receive a packet from every other player in the game within that time cycle window, the game will wait until that information is received and move the gamestate forward. Which means: the game will lag. Obviously, the higher the turn rate, the more frequently information is exchanged, which means your ping to other players has to support it. For example, if you're hosting a TR16 game and someone has a ping to you of greater than 62ms, the game is going to lag.


Second, the bandwidth question. The packets that Starcraft sends are very small (remember, this is a game that was tuned for dialup speeds of 14.4-28.8kbps upstream, but also most games don't require very much bandwidth anyway). I asked the hypothetical "if a packet is 10KB does that mean at TR16 you're sending 160KB/s?" and he said the packets were way smaller than 10KB. One data point he told me was that in one game with 6 players on TR08, 15 minutes long, there was around 1.2MB sent and received. That's about 1.3KB per second in a 6 player game. Completely negligible when it comes to bandwidth consumption.

The takeaway here is that it doesn't matter if you have a 10mbps connection or 100mbps or 1000mbps. You're only dealing with around 10kbps traffic on the high end. Any remotely-modern connection supports that. What does matter is the latency between players. TR08 is a good conservative estimate because generally any information can get anywhere in the world and back within 250ms. If that target is any lower, you start excluding some parts of the world. Like LoucMachine says, we're all bottlenecked by the speed of light.

Hi folks!

As we promised in our 2019 Priorities 67 list, over the last 12 months we've been working on some improvements to our global matchmaker.

Although I'm always in favor of full transparency with the community, we've done a couple of deployments in secret so that the placebo effect wouldn't taint the results. I figured if we made actual progress, we'd hear about it one way or another. After our last deployment on 8/8, that was certainly the case 107! It seems the new algorithm has been favorably received across the board, and has provided a significant improvement to global matchmaking.

So what's changed?

The primary change has been to use actual ping data from your PC to one of our data centers as a variable in the calculation of estimated latency based on region. This provides a more accurate prediction of what Turn Rate (TR) you're likely to achieve when matching other players. This also means that players who were previously using VPNs no longer need to use them - and you may see better latency from not using them.

Let's talk about Latency and Turn Rates

I've seen a lot of speculation about latency and turn rates and what was and what is, so let's dive into the math and history a little bit.

StarCraft uses a turn locked networking model. You can think of this as playing a board game - everybody takes their turn, and we can only move on to the next round once everybody's turn is agreed upon and resolved. In StarCraft, everybody's turn is happening simultaneously, but the important part is that we can only move onto the next round when everybody's current turn is done. Now, turns happen a little faster in StarCraft than a board game - StarCraft is capable of processing up to 24 turns every second. We call this the Turn Rate (TR). So TR24 means 24 turns are being processed per second. However, input processing happens faster than this, which means we can provide multiple actions per turn.

Prior to 1.18, StarCraft's codebase supported 3 possible TRs - 24, 12, and 8. In LAN, the game was configured to use TR24. In Battlenet, it was TR8. Over the years, community developers created addons, which offered the ability to change the TR inside StarCraft. They used an L notation to achieve this - L1, L2, and L3. This translated to 24 / L. In other words L1 was TR24, L2 was TR12, and L3 was TR8. LatencyChanger 64 was an example of such an addon.

In SCR, we expanded the code to allow any TR (up to 24, the maximum that the SC engine permits). This opened the door to TR10, TR14, TR16, and eventually TR20. We also added a Dynamic Turn Rate system (DTR), where the code will adjust the turn rate in response to the in-game latency.

The cold hard math

Now that the background is covered, there are a couple of formulae that underpin all of this.

Given the latency to my opponent, what is the best TR that we can hope for?
PredictedTR = 1000 * (UserDelay + 1) / Latency

For us to achieve a certain TR, what latency do I require to my opponent?
MaxLatencyPermitted = (1000 * (UserDelay + 1)) / TR

UserDelay is:

2 for Low Latency

3 for High Latency

4 for Extra High Latency

For full disclosure, UserDelay is a variable I'm using since I've seen it used in other community posts/sites. Under the hood, UserDelay is a calculation from other variables, but it's not really helpful to grok the details of that since it always resolves to 2, 3, or 4 in SCR. It may have been different values in 1.16 or earlier.

Using formula 2, we can easily throw together this table for quick comparison of TRs, UserDelays, and Latencies:

Code

TR    Low latency     High latency     Extra high latency
24    125             167              208
20    150             200              250
16    188             250              313
14    214             286              357
12    250             333              417
10    300             400              500
8     375             500              625

What this table shows is the maximum ms latency you can have to your opponent to achieve the TR listed on the left. For example: if you have a latency of 200ms to your opponent, you can expect to achieve:

TR14 if you only want Low Latency,

TR20 if you're OK with High Latency,

TR24 if you're OK with Extra High Latency.

What are these Latency settings (Low, High, Extra High) anyway?

Essentially, the Latency settings describe how many turns are “in flight”. If we return to my board game example, playing the board game on Extra High latency would be akin to announcing your current turn to your opponents plus your next four upcoming turns. You could also think of it as buffering in the same way as YouTube or Netflix works (except a really, really small buffer in our case!). And just like Netflix, the buffering removes stuttering and provides a smoother experience at the expense of responsiveness. On the other hand, insisting on playing at a TR beyond that which your connection can sustain will introduce a different type of lag - a stuttering experience as the game waits for the next turn to be received and confirmed by all players.

So what's next?

Since launch, we've rolled out numerous improvements to vastly improve on StarCraft's networking well beyond that offered in 1.16:

- Dynamic Turn Rate (DTR)
- TRs 10, 12, 14, 16, 20, and 24 on Battlenet.
- STUN servers
- Proxy servers
- Continual iteration of the matchmaking algorithm to support both our high population, low latency Korean players and our lower population, higher latency foreign population
- Bug fixes to the underlying networking layer

At some point, though, there's a hard limit, and that's the latency between two players. Latency is often a factor of distance, though other factors can also (sometimes precipitously) increase latency such as playing over wifi, the quality of internet in regions between you and your opponent, the quality of wiring at your or your opponent's location, and so on. If you want to get an idea of your latency, there are various sites that run a battery of latency tests to data centers such as Google, Amazon, etc. This is certainly not a 100% accurate report, but it will give you an idea of the best TR you can hope to achieve against each region (and you're probably most interested in Korea).

So, certainly we're limited by the physicality of the internet and factors outside of the game's control, but we'll continue to tweak the matchmaker with the goal of being as inclusive as possible and getting as many people matching as we can!

Last but not least: a word of thanks

It seems like a good time to thank everyone involved in this community for, well, being the greatest, most passionate gaming community on the planet, and helping us level up our matchmaker with continual feedback. I'd also like to give a special shoutout to SuGo, who provided us with some fantastic data - VODs, testing, and accurate feedback to help us very quickly identify one of the final bugs in the new algorithm which paved the way for a new release on 8/8.