Low Bandwidth issues with Telekom - Germany only!

I have had issues right from the launch of MSFS. About 90% of my MSFS sessions suffer from long load times, waiting at load screens (frequently 10 or more minutes), degraded aerials.

10% of sessions are not affected, and then I get to enjoy lightning fast load times, smooth navigation through the career mode UI, and perfect scenery.

I am a Telekom DSL customer, but I run my own DNS, DHCP etc. server in my local network, I don’t rely on any services from Telekom except the transport of data packets. My DNS server forwards requests to the public Google DNS servers, and has done so for years. I feel I can say with confidence that avoiding the Telekom DNS servers did nothing for me.

If some of your MSFS sessions run fine, for whatever reason, it’s easy to assume that the last thing you tried made a difference. Some people say Cloudflare Warp helps them, but a traceroute to any Microsoft service (e.g. forums.flightsimulator.com) tells me that there’s a direct connection (“peering”) from Deutsche Telekom to Microsoft’s network (in fact, there’s only one hop, a single intermediary step, between my DSL router and the next node of Microsoft’s network (judging from the hostname *.ber30-* that node could be in Berlin, not far from where I live).

image

On the other hand, Telekom and Cloudflare do not have a peering agreement. When Telekom users use Warp, their traffic goes through Telekom, a 3rd party transfer net, to Cloudflare, and eventually to Microsoft’s network. That’s at least two extra steps. Because all those data packets try to stay as local as possible, it might end up in the same Azure datacenter as before, but it might also end up in a different one. I tried Warp, and as expected, the result was the same with and without: some of the time MSFS works fine, a lot of the time it doesn’t.

Warp allows switching between Telekom and Cloudflare “on the fly”, and that probably causes client connections which were hanging, starved waiting for data, to be reset. The client (ie. MSFS) will retry, and if you’re lucky, this time the request will go through, so you get the impression that “with Warp, it’s better”. There might be some confirmation bias at play.

Warp might even work reliably for some people – the fact that it does not improve the situation for others could point to differences in network topology: Telekom users using Warp in one part of Germany might end up in the same data center as before, users in other parts of Germany might end up in a datacenter in the Netherlands or the UK, network topology can be funny like that. [Yeah, I know, I said before that data packets try to stay local, but that’s an oversimplification. Let’s say they try to take the “cheapest” route, the “cost” being evaluated in time and money. Reaching a data center in, let’s say, Amsterdam might be faster and cheaper for CF in some parts of Germany, but not in others.]

I’ve heard a lot of times that a VPN helps. Warp is a bit like a VPN, but it intentionally keeps traffic as local as possible, while a “real” VPN service will allow you to pick an exit node in a different country, even on a different continent.

I totally believe that a VPN does help. If you force your data packets to travel to another continent, you will almost certainly end up in a different Azure datacenter, local to your exit node. And even though the path of the packet takes a lot longer, even if the VPN provider skimps on your bandwidth, if the server on the other side is a-rockin’, you will have a better experience than accessing the server local to you – if you’re affected by the issues discussed in this thread.

By the way, while I’m composing this novella, I’m waiting for a Cargo Transport mission to start. I planned to keep writing until it loads, but I’m running out of steam.

Anyway, just like a VPN has a high chance of working around the issues (because, as I believe, different Azure datacenter = no problem), so does changing the ISP. I’ve noticed that, e.g., Vodafone and Pyur customers have a good experience – it would be interesting to know whether they end up in a different Azure location than Telekom customers.

I’m gonna find out. Pyur had a Black Friday offer (crazy cheap for 1Gbps, but apparently with certain limitations like CGNAT, forced Wlan “community” etc. – stuff that, for me, is unacceptable from my primary ISP, so I have to keep Telekom, too). I’ll have a 2nd ISP by tomorrow. A dedicated internet connection for my gaming PC, which I use mainly for flight simming. So, yeah, this is how far we have come. I would join the chorus of people telling Telekom customers to delete their rolling cache, change their DNS server, or sacrifice a goat, but I hope to be flying instead.

PS: Still waiting for the mission to load.

PPS: Still waiting. I think I’ll kill MSFS from task manager. But before I do, this:

Funny story about this image: it only shows completed requests, ie. requests that got a response that resulted in a status code. What’s missing are incomplete requests that got stuck somewhere during the negotiation. And requests that never complete because the data transfer stalls might show up as green or not at all, depending on how the server handles logging. Also, if there’s a problem affecting only one of many instances of a certain server, those problems might be drowned out by all the successful connections of people enjoying the sim.

Show me some pie charts for the server instances that serve me, with the percentage of TCP connections that were closed, reset, or timed out. I’m betting money on it (literally, by ordering a 2nd line) that they don’t all look so green.

PPPS: Never encountered a single CTD. But I frequently have to use Task Manager to get rid of MSFS when it hangs forever and becomes totally unresponsive. Wouldn’t it be nice if at least the Esc key and Quit to desktop would still keep working when there are network issues?

5 Likes