EPT1. Battle.net Structure
When you login to Battle.net you connect to the logon server and a few other servers you fetch web content from. The logon server provides the menu interface, the games are played on different servers you connect to when you host/join a game. These servers are clustered in different server groups and can have different geographical locations. To which server group you will get assigned doesnt look to depend on your geographical location. Also you are not assigned only to a specific server group. Below is a list of the different server groups.
+ Show Spoiler +
EU: 80.239.188.* - Frankfurt 195.12.229.* - Paris
NA: 12.130.193.* - New York 12.129.202.* - Los Angeles
KR/TW: 222.231.22.* - Seoul
SEA: 202.9.67.* - Singapore
As we can see the NA game servers are located on the opposite sides of the US, which means that your in-game latency can vary depending on your location and the server you are assigned to.
2. Correlation between in-game latency and ping. In-game latency estimation.
I did several in-game latency tests on the different servers from two different internet connections and then a simple linear regression on the results. The test procedure is described below.
+ Show Spoiler +
Recording with FRAPS at 60fps, the fps should not drop under 60 during recording, else "recording lag" can skew the measurements. A unit is given the move command 20 times. The recorded movie is loaded in VirtualDub, for each "move sequence" the time of the first frame where the cursor animation appears and the time of the first frame where the move arrow lights up are recorded. Then the 2 values are subtracted, the average of the 20 values is build. Sporadical lag spikes are disregarded, if there are more then 2-3 lag spikes in a set (indicates unstable connection with the server) the set is not evaluated. The tests are conducted during off-peak server hours.
The average ping to the server is build from the average readings of the last two hops from a few traceroutes to the specific game server (not the logon server), again if the readings fluctuate an in-game latency test is not conducted.
![[image loading]](http://imageshack.us/photo/my-images/534/chartfg.png/)
The red line is the regression line and it gives you the formula to estimate your average in-game latency based on your average ping to the game server (the conditional mean of Y for a given value of X, X is assumed to be fixed in repeated sampling), each dot is a pair of values obtained through the above procedure. The area between the green lines is a 95% confidence interval for an individual Y (Avg. In-game Latency) corresponding to a given X (Avg. Ping), i.e. 95 out of 100 times the true value of Y for a given X will be in this interval.
As we can see there is a minimal in-game latency of about 200 on top of which your ping to the server is added in almost 1:1 ratio.
To get a good estimate using the above formula a stable ping to the game server is assumed (your last hop ping values from a few traceroutes should not fluctuate much).
3. Differences between UDP and TCP modes.
Starcraft 2 supports both the TCP and UDP protocols. By default it uses UDP, but it switches to TCP if UDP is blocked.
-TCP: breaks the data into packets, retransmits the data if a packet gets lost or it arrives out of order
-UDP: sends the data as fast as possible, doesnt care if it arrives out of order or it gets lost
Obviously for gaming UDP is the better protocol, especially for lousy internet connections. Now lets see how Starcraft2 will behave on a stable connection using the different protocols. A few tests were conducted using the procedure described above on the same server groups using UDP, TCP and TCP with Nagle's algorithm disabled (this makes TCP to send small packets immediately without combining them into larger packets). The results are below.
+ Show Spoiler +
32/240.21 EU UDP [RTT/In-game Latency/Location/Protocol]
32/243.94 EU TCP
32/233.15 EU UDP
32/229.78 EU TCP/AckFreq=1
32/239.31 EU TCP/AckFreq=1
190/392.05 LA TCP
190/391.10 LA UDP
190/384.15 LA UDP
190/381.47 LA TCP/AckFreq=1
190/381.57 LA TCP/AckFreq=1
185/380.78 LA TCP/AckFreq=1
330/536.78 KR UDP
335/537.22 KR TCP
335/535.10 KR TCP/AckFreq=1
As we can see the differences between the three are insignificant. The advantage of using TCP over UDP is that you can tunnel it over the SSH protocol to a server and use the alternative route to avoid connection issues between you and the game server. Of course you can use UDP too with a VPN.
4. Calculating the room for improvement.
Using the above formula you can calculate the "best case" in-game latency you will get with your internet connection from your geographical location to a given server. As the formula is a function of your ping to the server the best possible in-game latency will be given by: Your latency to the nearest big internet-hub city + lowest possible latency from there to the destination. The second part you can calculate from the latency map.
![[image loading]](http://s3.postimage.org/2qx2i5284/ping.jpg)
Once you have determined the best ping you can get you can compare it with the ping you are actually getting. The difference will be the amount by which you can potentially decrease your in-game latency. A decent value will be under 20ms over the optimal value.
5. Possible ways of lowering your latency.
If your "best case" latency is much lower then your actual latency and you think the game is playable at this level of latency you can improve it by connecting to an intermediate server which can help you by either routing you through a shorter path or through a different non-congested path. You can view it as a "virtual multihoming" for the home user. The intermediate server can either be a VPN or some of these "low latency" services which run over SSH, or something else. What you want is the sum "latency to the intermediate server + latency from the intermediate server to the destination server" to be as close as possible to the optimum latency for you. There are a few problems with that concept:
(1) Most of the time you dont know what the routing from intermediate server to the destination server will be (i.e. you cant free trial VPNs or you use an SSH tunnel) . The route may not be optimal.
(2) Routing tables change. The good route you got can change.
(3) The route from the intermediate to the destination server can get congested too.
(4) The route from you to the intermediate server can get congested too.
Because of these problems its advisable to choose a server that gives you a good latency and is located as close as possible to your destination server (to avoid (1) and (3)) and to have as much as possible alternative servers in the same location (to avoid (2) and (4)). Below are two examples.
+ Show Spoiler +
Example: You want to play on the Korean server from NA but your ping to it is much higher then it should be. Lets assume that the lag is not caused by your internet provider but by the uplink provider of the Bnet server. Obviously the route to the Bnet server is congested/sub-optimal and you want to use a better route to Korea. You need to find a Korean based server which has low latency to you (so you dont lag) and will hopefully have a direct local peering with the Bnet upstream provider. In Asia most of the ISPs are not very peering friendly so the closer the server is to its destination the better. Also you will want to have at least a few Korean servers with decent routes you can connect to (mainly because of (2)+(4)).
It will be wrong to connect to a West Coast server instead since it will be very likely that it will route the data through to the same congested upstream provider and it will lag again.
Example 2: You are in Australia and you are lagging to NA. Normally you would want to connect to a low-latency West Coast server but if you are using Optus it can turn out that you are lagging to all West Coast servers too (since Optus routes almost everything to its West Coast POP and then peers with International ISPs). In this case you would need to connect to a domestic server and hope that it will use a non-congested network for transit to the West Coast. Since you may not know what the routing will be you will need to test the in-game latency and match it to the average ping expected for such a latency. If the expected ping for such in-game latency is too high then the routing from the AUS server to the West Coast is not good and you need to find a different server.
-When these services could be useful:
1) For NA to KR. Since most of the internet traffic stays in Korea (Koreans browse Korean sites) and international bandwidth is expensive the telecom companies dont purchase a lot of international capacity, this creates congestions during peak hours.
2) For AUS/NZ/SEA to SEA/KR/NA. Again congestions + routing issues.
-When you will probably have no gain from using such a service:
1) Your latency to the game server is already low enough. Then using such a service will be useless. Examples below.
+ Show Spoiler +
Both Proxy servers are located in the same city as the Bnet servers.
30/242 EU Direct
39/243 EU Proxy TCP/SSH
190/391.10 LA Direct
180/387.68 LA Proxy TCP/SSH
2) EU to NA. EU-NA links usually dont suffer from congestion problems and bad routes dont increase your latency with more then 20ms.
3) EU to KR. EU to KR routed through either NA or the Indian Ocean is about 280-300ms latency in the best case, which is probably still too high. The only low-latency route to Korea is through Russia but it will be costly.
The good thing is that most "low-ping" services offer free trials so you can test them out to check if they will be useful.
6. Tunneling Starcraft 2 through SSH.
If you want to try out these "low ping" services here is how to tunnel Starcraft2 over SSH.
You can play now on the different servers in "Starter Edition" mode.
Note that you should use SSH tunneling on your own risk, Blizzard can ban you for using such services.
1. Block UDP for the latest version of SC2.exe . This will make SC2 switch to TCP mode. SSH supports only TCP port forwarding.
2. Get an SSH client you will use to connect to the remote SSH server, for example Putty.
3. Go to the websites of these "low-ping" services and find their server list. Most of them offer preconfigured Putty clients that are loaded with the server list. If you dont have a preconfigured Putty client just enter the IP of the server and connect either to the default port 22 or to port 443, most of the time the SSH servers listen on these ports. Dont download their "proxy software", it does the same thing you will do but it doesnt allow for any kind of customization (i.e. what program to tunnel, to which destination to tunnel).
4. Once you have established a connection to the remote SSH server your SSH client will usually create a local SOCKS service listening on some port. If you are using Putty the default port for the SOCKS service is 443, if you are using some preconfigured version of Putty this can be changed, so check in your firewall on which local port Putty is listening. You can change this port under SSH->Tunnels.
5. Now you need a program that will allow you to redirect the traffic for Starcraft2 through the local SOCKS server which your SSH client created. There are many clients, good ones for Windows are ProxyCap or Proxifier.
6. Next you need to add this SOCKS server in your SOCKS client and create rules for the traffic to be proxied. Add a SOCKS5 type server with 127.0.0.1 as an address, the server port should be the same port as the one your SSH client is listening to.
Change the rules to "Proxy only" and add the latest version of SC2.exe. Add only the IP range(s) of the game servers and port 1119. Doing so will make that only traffic generated by SC2.exe to the game servers is being tunneled through the SSH connection, this means that your direct connection will be used to download patches and you login with your own IP (so your account data doesnt pass through the proxy tunnel and you dont login using different IPs).
