As the tittle states, it’s taking me hours to download the sim on a fiber connection that is gigabit up and down. Is there anyway to accelerate this or is this simply how slow the servers the sim hosted on are?
You can only download as fast as whatever is sending the data is serving it out. It could be your ISP, or load balancing or any one of a number of things. I have 200Mb and can sometimes get downloads faster than my mate who has 500Mb, usually it’s about the same speed though.
I have the same issue. I have a 5g connection and normal speeds are 800-1200 Mbps. If I download anything from Microsoft such as things from the Microsoft Store, Windows Updates and MSFS I’m lucky to see 100 Mbps.
My only solution is to use a geo located VPN. When connected to the VPN I will get decent speeds. I have no idea if its the ISP that’s throttling it, which would be odd seeing as the only things that are throttled are from Microsoft…
The speed of your connection is only guaranteed to your ISP’s servers and beyond that it’s a lottery. I only have a 50Mb service which is always solid so I can’t check but has anyone tried limiting their speed to say 250Mb in the MSFS data menu? I don’t think the MSFS servers will do much more unless you actually live right on top of them.
I tried every trick in the book after waiting two days for one of the beta’s to install a while back. After I saw that someone with similar slow download issues had luck with a VPN I coughed up the cash and huzzah. Not that I agree with spending money to increase my download speed but it’s the only thing that worked.
It’s purely Microsoft stuff for me - ANYTHING from the Microsoft Store is slow, often takes a long time to start, hesitates then speeds up, etc.
By contrast, downloading an 80GB game from Steam takes just a few minutes; same for GOG; the Epic Game Store; etc.
Go figure.
It’s also dependent on how the packages are sent. MSFS isn’t being sent as a single 90 GB file continuously, which would speed up the process. Instead, the packages are broken down to tens of thousands of small file packages. These are sent compressed, then once it arrives in your PC, the sim will unpack and uncompress them to be usable. This process takes time.
It’s similar to how storage disks behaves. It’s significantly faster to transfer 1x 10 GB file. Than 10,000x 1 MB files even if the total size is exactly the same because of the overhead of initialising, transferring, verifying each file every time instead of doing it once on a single larger file.
It is what it is.
LOTS of posts on this topic, even a post from Microsoft on it. Changing the DNS ultimately fixed my troules
All versions - Slow download speed – Microsoft Flight Simulator Support (zendesk.com)
Did you use the Google DNS as suggested in that link?
your connection does not matter. you are throttled by the download servers to whatever it was… its a specific number, not sure if same for everybody or changes based on region.
Troubleshoot in this order:
- Try google or cloudflare DNS
- VPN
Certain ISP/Regions have bad peering/routing with particular servers (Microsoft in this case). Raw bandwidth is not everything.
With all due respect, what you wrote is incorrect. Whether a file is sent as one big file or a bunch of little files it is still sent as a series of ~1500 byte packets during a single TCP session (assuming FTP or some other connection oriented protocol).
In your example, again assuming that TCP is in use, the network doesn’t wait until the entire 10Gb file is set to verify receipt. The session starts with a SYN and sends ACKs after each packet is received (up to your maximum supported MTU size in this case ~1500 bytes) until the 10Gb is completed and sends a FIN at which point the application understands the entire file has been transferred and does a Checksum to ensure that the file isn’t corrupted. The problem is if you just send one big 10Gb file and the checksum fails (the file is corrupt) then you have to resend the ENTIRE 10Gb file from scratch. That would be a bad thing.
On the other hand, if there are 10,0000 1MB files, once the initial network session is established you don’t need to reestablish a new session after each file has been transferred so there is no increase of overhead. And since you can verify checksums very quickly on smaller files, if a single file is corrupt (as is often the case over Internet connections with high packet loss) then you can send that one file again rather than the entire series of files. Overhead would not be any different because you are still sending a bunch of 1500 byte packets during a single session.
The only problem that could increase overhead is if your MTU size is set too small on your router, switch, or NIC which causes the packet to be fragmented into multiple smaller parts which does increase overhead due to reduced transmission efficiency. Most consumer routers come with an MTU size of 1472 to account for the 28 bytes of overhead = 1500 MTU to avoid fragmentation. But as shown above, it has nothing to do with the size of files being sent in a single session.
HTH,
Mike T.
I always assumed it was latency for the individual files. I see the DL bandwidth shoot way up when it’s a large file. When hundreds to thousands of those tiny files come through I can see my bandwidth usage go to near dialup speeds.
Michail - Bandwidth is bandwidth - it doesn’t care about file sizes or file types, so given a good connection to the files it should be no different whether you are sending a big file, a small file, or series of streaming packets as you would when you are in a voice or video call. Latency is not a function of file type, it is a function of time for packets to travel round trip to the host server. I
With that said, if you are seeing issues with certain types of files it could be anything from DNS to a misconfigured network setting, or issues with your router, switch, NIC card, location of the files in relation to your location causing high latency, lossy internet connection, or even your service provider throttling things. Also, if you are using a Wi-Fi connection there could be a whole other slew of issues which is why you should use a wired connection to your router if possible when using MSFS. Wi-Fi will always have higher latency than a wired connection.
HTH,
Mike T.
That’s assuming nothing is occuring in the client or server between files. Perhaps there isn’t and it’s just a single file stream that"s decompressing on the fly. It’s just not what I’ve observed on the installer for whatever reason.
I’ve written plenty of code that streams over networks and the way the code it written can have a huge impact. Even the payload designs on web pages can make a difference.
We would need to examine the source code of the installer or run a network trace to know for sure.
The thing here is we’re not connecting to one server, we are connecting to some sort of CDN. And before you get to that you will have your ISP’s traffic shaping / bandwidth management to contend with.
The ISP’s employ lots of systems which dynamically manage utilisation on their network depending on demand content type etc. After that, the CDN also employs load balancing, filtering, throughput limiting and all sorts, so in effect we have one consistent set of restrictions for all MSFS users (that would be the Microsoft / Xbox CDN) and then we will all have another set of restrictions depending on ISP, type of connection (4/5G, Fibre, Cable, DSL, etc) and geographical regulations.
It seems to me that a large amount of data could be downloaded on demand the first time they are needed rather than all at once. But others here would know more than I.
That’s pretty much what the rolling cache does. As you fly over an area initially, it downloads the information and stores it in the cache, so that next time it is needed it doesn’t have to retrieve it from the cloud servers.
It’s not your network. As time passes the game is using less bandwidth per customer to the point of having ridiculously slow download speeds when installing game content (30 Mb). I didn’t see game using more than 200 Mb for months during daily operation.
Cheers