CPU Bug "Limited by Main Thread" is causing the bad FPS

They’re already working on that, and have done some changes in the past.
The problem that lies in moving processes to other threads, is that the new process needs to be synced up with the rest, which is handled by the main thread. So while you’re able to offload some workloads from the mainthread, the syncing will put some strain back on it.

It’s a limitation of how things work in a sim. In a tile based renderer (like you’ll see in Cinebench) it doesn’t matter if one thread is done sooner than the others, so you can load all cores equally (and to the max), the final picture only needs to be ‘in sync’ after the whole rendering process is done. This does not work for a sim.

So yes, there will be more improvements in the future, and DX12 might help a bit, but it’s the nature of the beast that there needs to be a main thread that keeps everything in sync, and this will always be a limitation.

MortThe2nd, I think you may be wasting your time trying to explain that here. Far too many people seem to pick up on buzzwords (‘multithreading’ and ‘optimisation’ being favourites) and see them as some sort of magical incantation programmers use to ‘make everything faster’. Such people don’t like being told that coding doesn’t work through magical incantation, and that it instead requires understanding what the code is actually doing…

1 Like

meh, it might be, but if only 1 or 2 people pick up something from it, it’s worth my key-strokes.

3 Likes

One KNOWN & PROVED cause of lowering FPS, is the AI Aircraft “BUG”

So PLEASE, go vote on this in the hope it gets more visibility at Asobo, and speeds up an eventual “BUG Fix”

2 Likes

i have a 7700k and turning off HT makes it worse, however, as @N6722C has pointed out, we have discovered along with my work that the AI Objects are persistent and permanent, once they are created. especially AI Aircraft. this is a serious drain on resources, most pertinent to RAM and CPU. it only affects GPU and VRAM when they are within draw distance, but, they are always using RAM and CPU just for being in the game. on my end, the Sim seems to task 2 of the cores and 2 of the logical threads, and in many cases, tasks all 4 cores and logicals.

i have 64GB of RAM also, and in one instance the Sim used up 51.6 GB of RAM in itself ! and resulted in a CTD, which resulted in a matching Event ID 2004 Resource Exhaustion.


unless the above issues are resolved, even DX12 is not going to be much of a fix on its own if the code still allows objects to remain within the sim even though you are hundreds to thousands of miles away, it still consumes resources.

To check memory consumption run Task Manager and jot down the MSFS memory every 15 minutes.

AI jets will likely be in the air beyond 3 hours, so a growth in memory consumption is to be expected…until you reach a steady state of AI planes landing as often as they take off.

You may be running out of memory. Keep an eye on the total memory consumption of Windows in TM.

Unfortunately, (from observation) it does not “seem” work like that !!!

As you fly along your route, AI aircraft are “spawned” in the air around you, with intentions to fly “somewhere”… maybe even with flight-plans.

They may eventually Land somewhere, but before they do, so many more get generated around you as you fly, and the faster you fly, the more you leave some behind you, and the more get spawned around you.

Note: They spawn in the air, not necessarily from airports.

So, even if you set the AI slider to a low value, (the slider determines HOW MANY spawn around you with, within a FIXED radius), the total number flying increases, as you fly around.

I have seen these numbers get up to 1000+ over time, which , while requiring only a very small amount of memory to “define”, does require enormous amount of CPU power to “control”, and hence the drop in FPS over time.

Fly from say LA to NY, and as you approach NY, there are still AI planes flying in the LA area, as well as masses that have been generated in your WAKE, flying maybe 1000’s of miles from where they originated from.

Its an upsetting analogy, but think of AI Planes as the Covid-19 virus, and you will get the picture.

This is a little “staged” … I flew in the Chicago Area for a time, and then Teleported to a new location for short periods, to speed up the AI Plane generation process…
By the time I took this Screen shot, AI Planes numbered 886+, and my FPS and CPU Load were TERRIBLE.

What is interesting is that the FPS, decreased, but then locked in at the Minimum 10.0 FPS
(100.00 ms == not 100.01 or 99.99 )
Even then, both CPU & GPU memory usage were NOT excessive

It does sound like an object management bug in the code.

As a former C++ developer I’ve seen plenty of problems like this, and they are usually avoidable once the developer has identified the problem.

If you file a Zendesk ticket, make sure you include your excellent analysis of the problem.

I am hope many file a ZenDesk report about this critical issue.

I did a lot of C# SimConnect based programming for FSX MP, and the destruction of AI Planes was always an issue (especially if they had been generated by someone else !!! )

2 Likes

Aghh! If every man and his dog can add AI planes we will be taken over by Skynet!

I did wonder why some flight names were prefixed “ruff” :grin:

Maybe the next MSFS version can have a shoot’em up mode. A hypersonic stealth jet that can take out networked AI planes, double points for big jets, and a high score table of course.

On a more serious note…

It seems like we need a cull-radius for AI planes, centered on our plane. That’s quick to compute and the main thread could trigger that every minute, for example.
Then every minute a few distant AI planes dissappear.

A hard limit on AI planes, like 100, is another solution with the most distant being removed when a new plane is spawned.

Distance is subtract lat/long, add squares, then compare to radius squared. Distance could be cached, new planes added in distance order to a list. Very CPU efficient and used in cad/cam software.

A reproducible workflow will grab the devs attention quickly.

This would be wrong over larger distances and this requires spherical geometry. However considering it is just for removing distant aircraft there is no need for an exact distance value. However even if using Euclidian distance, it will be wrong depending on the latitude.

In any case there are faster ways than Euclidian distance to compute distance (and more precise than Haversine):

Fast geodesic approximations with Cheap Ruler

Hope this helps!

1 Like

Well, that 100 plane LIMIT is what the slider should be setting, so it can be adjusted according to user factors, like CPU speed.

Really need :
2 sliders GA . Radius and Maximum Number (within that radius)
and
2 sliders Airline . Radius and Maximum Number (within that radius)

At the moment, the two sliders, just control the number generated within the current radius, ( 1 for GA, one for Airline) and ignores any outside, that are free to live as long as they want, and suck on your CPU till it dies.

With the 2 slider (per type), it will MAINTAIN up to a maximum traffic number (slider 1), within the (slider 2) defined radius (which is actually an rule that is very easy for Asobo program)

Currently the rule to to Generate up to the slider value, a max number of planes, within your current Fixed radius, and keep doing that on a regular basis, and NEVER destroy any AI Planes in the air … PERIOD.

1 Like

I’m not sure this is the best option because you’d expect simple things be simple.

In this case, the setting allows you to change ‘density’ of traffic and this is what it is meant for, which is a number of aircraft per area. In this case, area is a disk centered on the aircraft.

I believe you shouldn’t change density by disk size, rather by number of aircraft. Disk size should only depend on 2 factors: visually out of range (beneath earth curvature) and beyond radio reach (not enough radio power to hear), whichever of the two is the closest.

These alone (out of visual range and radio range) should govern when to remove a distant aircraft to free a slot for a newer one, and if the list is full and a new one should spawn, then the farthest from you according to these rules should be evicted then.

The setting governing traffic density then will just affect the list size, that is how many concurrent aircraft are flying around you inside the disk.

CptLucky you are mathematically spot on! Apart from the oblate spheroid WGS84 mapping that GPS and MCDUs use.

Two multiplies, add and compare should compile down to 4 CPU instructions. Despite the inaccuracies, like flying over the pole, it is an extremely fast way to identify planes way beyond visual or ATC limits and does not have to impact the render loop. Critically distant AI planes will be cleared up hundreds of miles away.

Other more accurate solutions are possible! I’m just trying to point out that Asbo can fix this runaway leak in probably a days work plus testing.

2 Likes

I still maintain what I think I said …

Given limitations on # of AI aircraft your PC can handle, you want to optimize what those aircraft are

You want to be able to set the Radius, which you would depending on your Aircraft type, GA (lo altitude, Airline, High altitude)

ie If Airline, and you are flying high, talking to center, you want to hear as many AI planes on your radio, that are on the center frequency, so you set a large Radius, and a reasonabe MAX number.

If you are GA, flying low, and may not even be going to talk to Center, you are more interested in other GA traffic, with maybe a few Airlines thrown in.

The point is, if BOTH # & radius are controllable, then the user can decide what AI Plane environment they want. If radius is FIXED by Asobo, at some Fixed size, then there is no choice, and one relies on ASOBO picking a fixed “one size fits all” Radius.

If Slider are clearly marked, Radius & Max Number, it is really Simpler to understand than just a single slider marked GA Plane !!!

But ASOBO will do what ASOBO will do, the details of which ASOBO will decide.
The Primary thing that Asobo “Must” achieve, is a controllable limit on the number of AI aircraft allowed to exist in the sim, at any one time.

Once the ability to Destroy Planes is programed in, I suspect it is more work to change the UI, to add the two extra sliders, than it is to write the code to use them !!!

BTW. IMHO, the UI needs some considerable work … Great big CHUNKY Buttons to press, but yet tiny, skimpy, thin sliders to try to capture with the mouse to move !!!

NEED Thicker Sliders !!!

I think I understand the logic behind your idea but I’m not sure how this would make it better for a simple reason: there is no GA and Airliner traffic around you, there is only traffic. There could be a point where in a GA aircraft you’re crossing a boundary (logical boundary) of an Airliner for example and the point of AI traffic around you is to be able to spot it visually and on the radio, whatever this ‘type’ of traffic might be (GA or Airliner). Furthermore, if you add GA and Airliner, you’ll soon have to add Gliders and Light aircraft obeying different rules on certain areas, etc…

In the end what only matters is what you can see and hear, and this is limited by your Altitude (which governs the visual disk distance with Earth curvature) and obstructions (mountains blocking radio waves and atmosphere absorbing radio waves power). Please note there is no fixed radius in using curvature because this depends on your altitude, but in this case this changes the effective density of aircraft. Therefore, the slider should represent the maximum density at a maximum flyable distance, or to make things just simpler, this should represent the number of maximum aircraft around you: take all aircraft, sort by distance, show only the N closest to you.

When you start talking “Radio range”, (altitude, terrain) then things get several orders of magnitude more complex. I’ve designed and programmed this for other Multiplayer Flight Sim.

While cool to be realistic, it is very much an overkill, unless you are in an environment with Human ATC, and radars that need to see all planes in a Controllers airspace,

But yes, basically, anything you cannot see (visually or with Tcas) and everything you cannot hear, because you are not on their frequency, may as well not exist (in the sim) as far as you are concerned, as a pilot, flying your plane.

But then, just how much other Traffic do you want (or YOU can handle), being on your frequency. Get to much, and you will NEVER get a word in edgeways when trying to talk to ATC.
In MSFS you have to STRICTLY “wait your turn” for a gap, sometimes, if TOO many aircraft are flying, it may take many minutes before you can talk to ATC, or they too you.

Great to simulate in a Sim, if you are up to that Challenge of all the issues for you as a pilot, that can cause,

And then there is also the Elephant in the room… How much traffic can your CPU handle !!
Clearly, at this time, that is the #1 priority to address.

As for Radius, line of sight, radio range etc, the exact details are probably best left to Asobo, who have the Big Picture (we hope)