Thanks GimbalAxis - that reply is most useful. I plan to install MSFS on a separate D: partition on a new 1 TB SSD - dedicated to MSFS - that I plan to purchase. I’m hoping that (excluding the boot & system restore partitions, which will be auto-generated), giving 150 GB for Win11 itself on C: will leave around 800 GB for MSFS. If MSFS base & world = ~ 130 GB, and I allow another 70GB for future mandatory updates & WU growth, and if I give 20GB to the rolling cache, that allows ~ 680 GB for the manual cache & addons, which I think should be enough.
Beechc23 has a good point. Another factor could be exactly when each of the downloads is uncompressed to it’s storage location, as well as what “processing” needs to take place.
For example, for the core install, the installer might download the entire app to a temporary location, and then decompress it to it’s final location, or, alternatively, decompress & write to file while downloading. In either case, it is likely just writing the decompressed files directly to an empty directory on disk without further processing.
For the world updates, there is an additional step (I guess) of replacing bits of the core with the updated data, including finding, analyzing & modifying configuration files and the like. If this is happening during the download - as opposed to downloading everything to a temporary location first & then starting actually updating stuff, then I could see delays as now you have multiple threads trying to write to disk - one or more for the downloading data, one or more for reading data to see what needs to change, and one or more for writing the decompressed data to disk.
So, the bottleneck might not all be due to the network or network servers. it could be disk (particularly if a HHD), memory or CPU contention, depending on your PC’s specs & how the installer is coded.
If you saw a regular cyclical pattern to the ups-and-downs, that would suggest to me that the installers is downloading & processing data in a sequence: i.e. downloading a “chunk” of data, then downloading another chunk on a background or lower-priority thread while decompressing & processing “chunk # 1”, then processing “chunk # 2” while downloading “chunk # 3”, etc. All “chunks” may not be the same size. This scenario, might explain why you saw periods where network activity was running below network capacity.
But without network traces, or CPU, Disk or Memory monitoring logs this is all speculation on my part. However, I do think trying to create an installer than can run optimally on a huge variety of different PC specs & network connections (download speeds, latency, etc.) is no easy thing.
I do agree with you that 24hrs is a very long time. Makes me wonder how long my download will be!