EU fallback for London 2038

What’s the story behind this?

We have been investigating reports about bad “ping” and/or disconnects that seem to occur especially during European evening hours. It predominantly affects a number of our German users who are customers of Deutsche Telekom AG (DTAG) or their resellers (like 1&1). There are strong indications that – for some parts of their AS3320 network – the problem is caused by packets (originating at our US server) being routed via seabone.net (Sparkle). During times at question this “transit net” shows degraded performance at one of their IPs. Apparently that can get bad enough to severely impact London 2038 gameplay experience.

Network graph, timestamps are UTC. Intermittently there is around 40ms of added latency, plus notable packet loss (the horizontal lines turning blue where they should be green). Source: http://vin.smokeping.ovh.net/smokeping?target=EMEA.AS3320


How do I check if I’m affected?

  • When experiencing the symptoms open a powershell / command prompt and enter ping -n 30 shulgoth.london2038.com.
  • Check the output (summary) for signs of excessive packet loss:
Ping statistics for 135.148.151.102:
Packets: Sent = 30, Received = 26, Lost = 4 (13% loss),
Approximate round trip times in milli-seconds:
Minimum = 141ms, Maximum = 142ms, Average = 141ms

With the problem present it’s not unusual to see 20-25% loss at times.


What is the workaround?

We are now providing an additional connection endpoint for the game. If you consider using it, first check your network latency to our Frankfurt host, using the command ping fallback.london2038.com. Ideally it should be around 40ms or less.

If you deem it worthwhile you may attempt to switch to this alternative connection. Make sure to start the game using our London 2038 launcher. If needed this will download a new server list. Now at the login screen tick the checkbox “Show all” and then set the server to “Fallback 2038 (EU)”.

⚠ Please note that this is not a second/separate game server. It’s just a stopgap measure to circumvent the routing problem by providing a “forwarder” at a different location (and thus different network), for those that are frustrated by this very specific problem. Using it likely means some additional network latency. It may not work well – or at all – for you.