FSL Concorde - Core usage confusion

[Ray Proudfoot 9,038]

1 hour ago, kmax59 said:

The RenderAsync option in the ConcordeXgauges.ini seem to have a huge impact. My CPU and GPU usage did not change suprisingly, but the fps inside the sim is much better.
How is yours set?

Hi Maxime,

That’s a significant find, well done. I’ll have a look at my setting.  I’ll run a test with engines running at Heathrow before and after changing that value and see what changes.

1 hour ago, kmax59 said:

Pierre Chassang transmitted to me his passion for Concorde, I met him in real life and helped him a bit with CPS in the past, that was one of the most exciting times I had in my flight simulation career

I worked extensively with Pierre for several years on CPS-X and helped with the English version of his manual. I loved using CPS-X and do miss it. Sadly it’s not compatible with the new Concorde but it is with the X-Plane version. It would have been nice to meet him.

Sadly, my education didn’t include learning French so I wouldn’t be able to appreciate your video.

I’m out most of tomorrow so I’ll report back on Sunday.

[Afterburner 374]

Hello Maxime, I am glad to see that you are making progress with the performance of FSL Concorde on your PC by modifying the "RenderASync" entry. However, you mentioned that despite higher fps, your CPU load is still relatively low. This means that your PC power is not fully utilized and that there is room for improvement. You were wondering why your GPU load dropped when your fps dropped to 15. Well, that's quite simple: When the fps drops so low, the GPU is underutilized, hence it needs only little power to process the fewer frames per second.

Under normal circumstances, if you do not limit fps externally or via Vsync, either the CPU (on the main core) or GPU should run at 100%, while the fps should reach the maximum. This does not seem to be the case with your setup.

Your finding shows that the gremlin is hidden somewhere in the internal processing by the Concorde and not in your GPU or CPU. I hope that FS-Labs will disclose the meaning of the said entry and provide more suggestions on how to optimize the performance.

[Ray Proudfoot 9,038]

I've run a severe fps test at SimWings Heathrow and can confirm an improvement in performance even on my machine.

My test is as follows:-

From the Scenario screen select EGLL Rwy 09L and Concorde from the Aircraft menu.

You'll find your aircraft holding short of 09L and the before take-off checklist is running. Let it finish.

Then enter slew mode and press Q to raise the aircraft. At 500ft AGL press 5 to stop the ascent and move your aircraft just west of T5 facing due east. You should have the whole airport in view with London in the distance.

Now press 1 or 3 once. That starts the longtitudial rotation of the aircraft. Only press the key once. If you have RTSS monitor your fps. Mine is maxxed at 30 but I could never achieve that at Heathrow with Ai at 100%.

If you have GSX then disable it to prevent the reload airport cache running which disrupts the performance considerably.

Now watch both the fps and the view carefully. If you have 30 as your preferred refresh rate with VSync on is the movement free of any stuttering? With RenderASync=0 it wasn't for me. The fps dropped to 28 at the most complex time and soon recovered to 30. But it stuttered when < 30.

I then changed the value to 1 and repeated the test. This time 30 was achieved with no deviation. The rotation was stutter-free.

There's clearly a penalty for this value being 0. There may be other tweaks that improve performance further. This is a useful test as it doesn't need you to setup a flight.

But for now well done Maxime on finding the solution and getting a much improved performance. 👏 You deserve a huge amount of credit for locating the source of the problem.

Additional Info: Here's a screenshot of performance during this test. My AM settings are as follows:-

[JobScheduler]
AffinityMask=16777215
P3DCoreAffinityMask=16777215
MainThreadScheduler=6
RenderThreadScheduler=2
FrameWorkerThreadScheduler=4

As you can see both core 2 and 6 are heavily under-utilised. Core 5 is working hard but that could be a Concorde process doing that.

[Afterburner 374]

In my humble opinion, not only does Maxime deserve a huge amount of credit for his finding, but also an apology from the FSL developers!

I am saying this because when Maxime made his first post about performance issues back in August, none of the developers responded. Repeated reports about the bad performance were met with silence (or the issue was blamed on the mouse cursor problem). There was an announcement about performance optimizations, but it did not come to fruition. The thread was on the verge of being locked by the boss. Now, six months later, changing a parameter that was undocumented by the team worked almost wonders. I think that it was the developers who implemented this entry in the cfg, so they should properly document it, and they should have suggested to change it in Maxime's thread. Instead, it was a lucky finding after many hours of frustration that partially solved the problem for the user. Not a professional way of helping customers, if you ask me.

[Afterburner 374]

@Ray Proudfoot

It would be interesting to see your results and the CPU core load during an actual flight with engines running, not just using slew mode. I think that the load distribution you have posted may not be representative of an actual flight.

[Ray Proudfoot 9,038]

7 minutes ago, Afterburner said:

@Ray Proudfoot

It would be interesting to see your results and the CPU core load during an actual flight with engines running, not just using slew mode. I think that the load distribution you have posted may not be representative of an actual flight.

I flew EGCC-LPPT this morning and monitored performance. I’ll post a screenshot tomorrow but from memory the only real difference was cores 8-24 running consistently around 30% on average presumably loading scenery.

And just to confirm the engines were running in my above test. The “before takeoff checklist” had just been completed. The only difference to a real flight was I was stationary.

FSL staff are monitoring this topic.

[kmax59 213]

Thank you for the positive feedback Ray 😀 I'm glad this finally results in a true performance improvement, it's still pretty hard on frames, at least for me, but it now has acceptable performance, which is a true relief. I stopped flying Concorde since v4 was released and I really missed her since then, having this new version and not being able to use it was extremely frustrating.

By the way, are your running 100% AI without any cap? 😵 I wish I could. I usually run it at 100 as well in but then FSUIPC caps the aircraft number at 40 after they're generated, so there's traffic everywhere without hurting too much fps.

2 hours ago, Afterburner said:

In my humble opinion, not only does Maxime deserve a huge amount of credit for his finding, but also an apology from the FSL developers!

I am saying this because when Maxime made his first post about performance issues back in August, none of the developers responded. Repeated reports about the bad performance were met with silence (or the issue was blamed on the mouse cursor problem). There was an announcement about performance optimizations, but it did not come to fruition. The thread was on the verge of being locked by the boss. Now, six months later, changing a parameter that was undocumented by the team worked almost wonders. I think that it was the developers who implemented this entry in the cfg, so they should properly document it, and they should have suggested to change it in Maxime's thread. Instead, it was a lucky finding after many hours of frustration that partially solved the problem for the user. Not a professional way of helping customers, if you ask me.

Well, I totally understand what you are saying, however I don't want to blame them too much, as a dev I know it's not always the most comfortable position and managing issues you can't really reproduce is often pretty hard.

That being said, it was extremely frustrating to continously repeat what I did, what kind of performance I'm facing and to hear that I did not want to change my settings or similar things after spending so many hours reporting almost every single test I've already made. It was also quite irritating to hear from some of the beta testers that I was not not doing any efforts trying to adapt my settings (in other topics) while I think I did everything a customer could have done to solve fps issues. It's always tempting in such a case to say "hey I'm a dev, I know what I'm doing" but then it's often taken as arrogance (and being French does not help here 😂) and often brings the off-topic to another level, we saw that on my FSL topic which almost got closed as you said.

I would have managed this differently as a beta tester or as a dev, having an experience in both roles, but I also know it's not easy to be sure if a user says everything, I learnt this the hard way in my "dev career" 😅😇 It's always best to consider the customer is right at first though. So yes, I wish someone would have guided me to this solution much quicker but in the end if it allows them to enhance it further and help other users then better later than never.

Now let's hope it's getting even better in a not too long time frame 😁

Edited February 18 by kmax59

[Ray Proudfoot 9,038]

28 minutes ago, kmax59 said:

By the way, are your running 100% AI without any cap?

Yes, both Traffic sliders set to 100%. Around 100 on the ground at Heathrow and a similar number at LFPG, KLAX and KJFK.

Setting that one parameter to 1 allowed me to increase Ai slider from 85 to 100.

I fully agree with your observations about support. One reason why I’m unlikely to post there again. I’ll raise a ticket for any issues.

[Ray Proudfoot 9,038]

23 hours ago, Afterburner said:

@Ray Proudfoot

It would be interesting to see your results and the CPU core load during an actual flight with engines running, not just using slew mode. I think that the load distribution you have posted may not be representative of an actual flight.

Here's the situation landing at EGCC. 30fps maintained throughout as the Ai count at Manchester is <50.

[kmax59 213]

  

On 2/18/2024 at 5:08 PM, Afterburner said:

@Ray Proudfoot

It would be interesting to see your results and the CPU core load during an actual flight with engines running, not just using slew mode. I think that the load distribution you have posted may not be representative of an actual flight.

Hi @Ray Proudfoot, @Afterburner,

I'm currently in the middle of a flight from EGLL to KJFK (doing the tutorial flight again as I did not fly her for such a long time, I need a proper training again) and here is my CPU usage.
Note that I've decided to go using my previous affinitymask of 21845 (my previous performance tests confirmed it did not hurt my perf compared to default), meaning that only the physical cores should be used, which is not the case here. Does this means Concorde plays with the affinity? May be, honestly it's not that a big deal as long as it does not have a negative impact on performances but it'd be great to have an official answer on this.

Other than that, the flight is going well and for now, I haven't had any real performance issue other than the remaining and quite drastic mouse cursor drop

[Ray Proudfoot 9,038]

22 minutes ago, kmax59 said:

Note that I've decided to go using my previous affinitymask of 21845

That equates to 0101010101010101

I can see you have SMT enabled, hence the 16 logical processors. So reading from right to left you have one half of each processor assigned to P3D.

What are the assignments in the JobScheduler section?

[Afterburner 374]

@Ray Proudfoot  Can you tell me what the shaded part of the CPU load graph (beneath the bold one) represents?  I haven't seen it on my PC, so I am wondering.

@kmax59 I am glad to hear that you have finally had a chance to enjoy your flight with the Concorde. Do you have any fps cap enabled, and are you able to maintain that cap?  Also, if you use other airplanes, do you see odd cores active and even ones idle on your task manager CPU load graphs (the way it should be according to your AF settings)?  If yes, then it must be indeed the case that Concorde "plays" with the AF settings internally.

[Ray Proudfoot 9,038]

38 minutes ago, Afterburner said:

Can you tell me what the shaded part of the CPU load graph (beneath the bold one) represents?  I haven't seen it on my PC, so I am wondering.

I haven’t a clue. I was hoping you might tell me. It doesn’t match the numbers RTSS is showing but Bob Scott has advised there is general suspicion on other forums it’s reporting accurate numbers.

It’s there on Maxine’s post too.

[Ray Proudfoot 9,038]

A search reveals the answer. Kernel usage. It can be toggled on/off. I’ll turn it off tomorrow and see what usage looks like then.

https://answers.microsoft.com/en-us/windows/forum/all/task-manager-shows-something-unusual/5fa5804a-cf79-4934-99bc-6ef420be7258

[karajzk 1]

15 hours ago, kmax59 said:

 

Note that I've decided to go using my previous affinitymask of 21845 (my previous performance tests confirmed it did not hurt my perf compared to default), meaning that only the physical cores should be used, which is not the case here. Does this means Concorde plays with the affinity? May be, honestly it's not that a big deal as long as it does not have a negative impact on performances but it'd be great to have an official answer on this.

 

Back in August, I used process lasso in win10 to manage the affinity for running processes in all sims. Even in p3d addons it worked fine with everything except concorde. concorde kept overriding the affinity mask. If I set the process lasso to constantly monitor and enforce my affinity settings, concorde did the same, they fought each other, the affinity mask kept changing.

The renderasync setting you found improves performance significantly for me as well.