this is still a thing. MES1 - 150ms latency.
Hey there,
Lets go ahead and grab a winMTR so we can further investigate the problem. Here are the instructions:
- Download the tool from this page
- Enter the game IP into the “host” field. The IP address for our games are listed on the winMTR instructions page
- Start the test and play the affected game for at least 15 minutes. Ensure the problem happens while the winMTR tool is running.
- After recording the problem data, click “export text” and save the winMTR file in an easy to find location.
- Once you have that made, open the file. You’ll need to copy and paste the contents of the Text document into the post, and put four Tilde (~) marks above the winMTR. It’ll look like this:
WinMTR goes here
If you have issues pasting here, please use Pastebin and post the link (ex: Pastebin (dot) com/123456).
Hello and thanks for the reply!
I live in Germany and usually play on CDG1 or AMS1. These connections are fine in my opinion.
Recently, I have been put into games on MES1 a couple of times.
On these servers my latency is of course much higher( >150ms)
Unfortunately I can’t say why I was moved to MES1 servers or if it will happen again. Maybe you have an answer to this question.
I have attached the WinMTR results for a normal match (30 minutes botgame on ASM1).
|------------------------------------------------------------------------------------------|
| WinMTR statistics |
| Host - % | Sent | Recv | Best | Avrg | Wrst | Last |
|------------------------------------------------|------|------|------|------|------|------|
| 192.168.178.2 - 0 | 1752 | 1752 | 0 | 0 | 15 | 1 |
| 192.168.178.1 - 0 | 1752 | 1752 | 1 | 2 | 15 | 2 |
| p3e9bf389.dip0.t-ipconnect.de - 0 | 1752 | 1752 | 9 | 12 | 88 | 10 |
| 217.5.116.182 - 2 | 1539 | 1520 | 16 | 186 | 4962 | 969 |
| 217.5.116.182 - 2 | 1540 | 1521 | 16 | 186 | 4962 | 1000 |
| 62.157.248.74 - 0 | 1752 | 1752 | 16 | 21 | 156 | 17 |
| ae1-br01-eqfr5.as57976.net - 2 | 1654 | 1632 | 21 | 40 | 4161 | 38 |
| et-0-0-2-br01-eqam1.as57976.net - 3 | 1537 | 1496 | 21 | 151 | 4849 | 31 |
| 137.221.65.75 - 3 | 1568 | 1533 | 21 | 121 | 3972 | 23 |
| 137.221.78.49 - 0 | 1752 | 1752 | 21 | 25 | 149 | 23 |
| No response from host - 100 | 355 | 0 | 0 | 0 | 0 | 0 |
| No response from host - 100 | 355 | 0 | 0 | 0 | 0 | 0 |
| No response from host - 100 | 355 | 0 | 0 | 0 | 0 | 0 |
| No response from host - 100 | 355 | 0 | 0 | 0 | 0 | 0 |
| No response from host - 100 | 355 | 0 | 0 | 0 | 0 | 0 |
| No response from host - 100 | 355 | 0 | 0 | 0 | 0 | 0 |
| No response from host - 100 | 355 | 0 | 0 | 0 | 0 | 0 |
| No response from host - 100 | 355 | 0 | 0 | 0 | 0 | 0 |
| No response from host - 100 | 355 | 0 | 0 | 0 | 0 | 0 |
| No response from host - 100 | 355 | 0 | 0 | 0 | 0 | 0 |
| No response from host - 100 | 355 | 0 | 0 | 0 | 0 | 0 |
| No response from host - 100 | 355 | 0 | 0 | 0 | 0 | 0 |
| No response from host - 100 | 355 | 0 | 0 | 0 | 0 | 0 |
| No response from host - 100 | 355 | 0 | 0 | 0 | 0 | 0 |
| No response from host - 100 | 355 | 0 | 0 | 0 | 0 | 0 |
| No response from host - 100 | 355 | 0 | 0 | 0 | 0 | 0 |
| No response from host - 100 | 355 | 0 | 0 | 0 | 0 | 0 |
| No response from host - 100 | 355 | 0 | 0 | 0 | 0 | 0 |
| No response from host - 100 | 355 | 0 | 0 | 0 | 0 | 0 |
| No response from host - 100 | 355 | 0 | 0 | 0 | 0 | 0 |
|________________________________________________|______|______|______|______|______|______|
WinMTR v0.92 GPL V2 by Appnor MSP - Fully Managed Hosting & Cloud ProviderSome of the Deutsche Telekom addresses in the test are showing high ping and slight data loss before reaching the Blizzard servers.
1 Like
Yes, I agree.
Peering between DTAG and Blizzard Services has never been great in my experience, but has improved significantly in recent years.
However, the connection quality to CDG1 or AMS1 should always be significantly better than connecting to MES1.
I wonder why this happened, it would be really annoying if it happened in a competitive match.
The client checks the ping from itself to your location. It means the ping between you and CDG and AMS was higher than MES, or that there were no players available in your rank or mode selected to fill the party.
Both options sound very unlikely from my point of view, so it would be helpful if any Blizzard technical forum agent could still comment on this.
Thanks for your help, I appreciate it! 
Oh, okay. Then here you go:
This is a case with Australian players, but it’s applicable worldwide.
I checked again, I know in which data center the peering between DTAG and Blizzard takes place and that they are connected with 10gbit.
DTAG only peers in restricted mode. This means that Blizzard has a contract with DTAG for data exchange.
I think it is very unlikely that connection problems were responsible for sending me to a far distant game server.
That being said, CDG1 would have been a much better alternative as well.
On top of that, I played during prime time, so there was certainly no shortage of players.
No one is saying it was a connection problem. Routing tables change all the time and are not within Blizzard’s control. Plus, primetime or not doesn’t guarantee people in the mode/rank you’re playing are available.
So that has me curious, what are you suggesting is the reason you were placed elsewhere? Is your suggestion that Blizzard, a AAA title company, isn’t monitoring their server infrastructure and has some sort of problem going on that they’re keeping a secret?
I am not suggesting anything.
I simply reported a problem and noted that your explanation is highly unlikely. 
Peering between DTAG and Blizzard at equinix am2 won’t change from one minute to another. Because there are fixed agreements for this kind of exchange.
Since this problem didn’t occur all the years before, I would guess that something was changed in the prioritization for latency in matchmaking. But who knows!
I suggest we relax and wait for a blue post 
It is not urgent and I can wait.
It’s not mine, it’s an explanation from the staff posted in March of this year. It’s even from the same staff member who first responded here. Since the staff monitoring this forum have no hand in how matchmaking works, if you have feedback on how you were placed you’d want to post that in #general-discussion or #competitive-discussion as applicable.
Best of luck in how you decide to proceed.
1 Like
Ok I found a potential cause.
I have been playing in a group with a Middle Eastern player lately.
This player has blocked the MES servers so that as a group we never join such a server.
If I play solo for some time afterwards, the matchmaker still directs me to MES servers, even if I am not close to it at all. (several way better routes etc.)
Ultimately, the matchmaker decides which servers I play on.
it doesn’t matter what my current latency is, it always collects data from the past and decides based on that.
However, I do not know how long this process may take.
I was in, solo for about 7 games and then later directed to MES.
Why would you quote the example that was disproven several times in that same thread?
That thread not only proved it was not a single isp, single user, or single use case, but instead how google advertised GSG1 to Australians (and other regions such as India), and hence was a problem for every single player inside Western Australia, South Australia and Victoria.
It was also proven in that exact thread that the 60-80 ms was for Perth to an entirely different server than was mentioned (Syd2, not GSG1). It was disproven when the average latency figure was claimed back on November 3 2020 (Australian routing to Singapore server GSG1 broken, triple latency for Perth players - #8 by yedrellow-1214) that it was for GSG1, and it was disproven after the thread was closed with the exact same claim on March 29 (Elevated ping to GSG1 since nov 2020 - #7 by yedrellow-1214).
We spent dozens of man hours proving that the average latency figure mentioned was not for the same server, yet this still gets quoted for another region as the gold standard response to every latency issue.
Google just sucks at international routing, and Blizzard, despite being a AAA company does not want to spend the resources to maintain its playerbase in declining markets. Or rather, it does not particularly care if it loses the playerbase of entire regions just because it doesn’t want to get google to do the literal 1 hour of work to fix how google routes from PNI to PNI for games.
The MES1 latency situation is completely analogous to the GSG1 situation now that the routing is broken to it.
The crux of the problem is that Google treats every location inside “less important” geographically large countries/regions to be the same, and will always checkpoint its routing via the same google PNI regardless of whether that makes sense based on the destination. This is why a user in Calcutta’s route to Singapore goes:
Calcutta ----> Delhi ----> Singapore ---->Delhi -----> Calcutta
Or a user in Perth with the same destination goes:
Perth —> Sydney----> Singapore ----> Sydney ----> Perth
You only have to look at a map to understand why that’s a terrible route. Google in both cases forces its users to route pointlessly via its favored PNI in the same nation, regardless of geopraphy.
This is a fundamental problem with how google handles its routes for less significant regions, and definitely would be influencing at least some users routing to MES1.
Hey all,
This thread is getting a little off-track so I’m going to lock it up since there is no immediate “solution” to the issue that ADDERALL is describing.
yedrellow - We’ve already reached out to Google about the issue you’re describing and we haven’t heard back yet. We can’t force Google to change their routing, so the best we can do is report it up as we’ve done. If we have anything new to share about the situation we’ll make sure to post an update in the open thread that you linked.
ADDERALL - If you believe there’s a potential issue with the matchmaker that may be causing you to play on MSE1 servers after leaving party please report that in the #bug-report section. We don’t have the ability to investigate or fix bugs here on the Tech Support forums.
1 Like