2025.01.18 - v1.2.11.0 - Growing the Rolling Cache from 16 to 256 GB
So far my focus was on testing the default 16 GB size of the RollingCache.ccc file.
The primary insight that I gained from all the past tests was, that today the RC uses a strict Least Recently Used (LRU) cache replacement policy.
Based on that finding back on 2024.12.23 I did post the following “guess” for practical recommendations:
- Increase the size of your RC as much as possible
- … but I might change my opinion on this, once I take a closer look at the “tiny purple line” at the beginning of the cache.
- Especially the landscape data on long flights can and will wipe out important sim data
- … which then needs to be downloaded again if it only was in the RC.
- Sizes of up to 250 GB seem to be without noticable problems (so far).
- Sizes above 750 GB might be a waste of storage,
- … as the sim might not be able to use it all (due to the nature of the RC index structure).
- Once the feature gets added to FS2024, manually cache (aka. “Install”) as many relevant FS2024 Marketplace assets (aircraft, airports) as you can outside of the RC.
- This form of manually caching outside the RC will reliably reduce the need for network usage.
But that was theory … is that true in practice?
So with that background the first obvious question was:
- What is the nature of the data in the RC after a very long flight in a very large cache?
For that I did run the following test:
- Test A1 to A4
- I upgraded to sim hotfix v1.2.11.0
- I deleted the RC file … to trigger a clean rebuild of the RC.
- I waited until all the initial data for the cache arrived
- … which took some time, due to stressed servers in a rainy cloud.
- I restarted the sim … and raised the RC size to 256 GB.
- Test A5
- I took a long flight … 11,5 hours
- … from KSFO to KLAX to CYYZ
- … visiting the 3 TIN cities at low altitude.
- I took a long flight … 11,5 hours
As always I made system event recordings with the Process Monitor tool. For easier and more detailed analysis I exported the results to a more readable CSV file format.
What I did see during Test A5 was:
- Around 2.5 Mio new blob items have been added to the RC.
- That is around 200,000 items per hour.
- The average blob item size was around 30 KB.
- This translates to around 70 GB of new data in total
- … or 6 GB per hour
- … which on average is around 15 to 20 Mbps.
- … or 6 GB per hour
- Based on the 256 GB RC size
- … the 70 GB are around 27% of the available size.
With those more concrete blob item numbers I would now make the following index area observations:
- At 72 bytes per index item
- … the existing 2.5 Mio new blob items
- … require around 171 MB or index area space.
- Since that area has a fixed size of 512 MB
- … around 33% (1/3) of the index has been used up.
- So this means 3 * 70 “long flight” blob item GB will exhause the index area.
- … the existing 2.5 Mio new blob items
So with that I will revise my recommendation from 2024.12.23, which said:
- Sizes above 750 GB might be a waste of storage,
Today I would say:
- Sizes above 250 GB might be a waste of storage,
- … as the sim might not be able to use it all (due to the nature of the RC index structure).
However, I also stumbled over an issue, which I increasingly do consider a (major) performance issue of large cache sizes. I will try to explain that in the next post … and until then I will leave you with this … cliff hanger.