couatl.exe cpu usage in the cruise

[sw34669]

Hi

Ive noticed that couatl.exe when in the cruise > FL200 uses 1-3% of my cpu cycles. I thought GSX/couatl was disabled at altitude. Ive sat and watched it with process explorer and in a 2 hour flight it clocked up 1.5 hours of cpu time .

Ive been looking for the cause of some microstuttering i had in flight and if i kill off couatl.exe the stutter vanishes.

Im on p3d 4.3 / windows 7 / on a 5960x@4.6Ghz with 2 SLI 980ti's.

What is the scripting engine doing when in the cruise ? thanks

[virtuali]

GSX is disabled while cruising, but "disabled" only means it won't try to look for airports around you in case you need to pre-select a gate when still in flight, but that doesn't mean it's totally and entirely turned off.

Of course, it must still check, at very low update intervals (ever 4 seconds, which is the lowest Simconnect allows), when you are starting your descent so, basically, it will still check your altitude and airspeed, but that's about it.

1-3% of your CPU cycles is nothing and it's entirely normal (I'm sure you have lots of other processes running taking more cycles) and, under DEFAULT conditions, the OS should take these cycles from a spare core of the CPU, so normally you shouldn't be able to see any impact of GSX, just because it's running.

However, if you played with the AffinityMask settings, overriding what the OS is doing to handle spare CPU cycles, it's possible you are working against the OS so, the first thing to try is to remove any tweak to the AffinityMask and use all default.

And, if you have Hyper-Threading enabled, try to disable it in the BIOS, because all reports seems to indicate P3D works more smoothly when HT is disabled.

[sw34669]

Umberto,
Thanks for the thoughts, ive also dropped HT off for the moment whilst I try and find the issue i think
high mutex with p3d plus a load of add-ons sometimes does not fit well with HT.
I conclude that this was a simconnect (in the London FIR) flooding issue driven by Ultimate Traffic (not)Live. The more load gets put on SC the more its clients ping it to get a reply, or re-try.
scott.

[torsten]

Of course, it must still check, at very low update intervals (ever 4 seconds, which is the lowest Simconnect allows), when you are starting your descent so, basically, it will still check your altitude and airspeed, but that's about it.

with my proposel, you don't need to do that

[virtuali]

with my proposel, you don't need to do that

If, with "your proposal" you mean the ability to preselect a gate related to the flight plan, is an entirely different issue, won't change anything and won't make any difference to the requirement that Couatl would still have to run in the background, if only to be ready to be available again on landing.

Not that this could make any difference with this thread that, as usual, turned out to be a problem caused by another addon flooding Simconnect with commands so, the stuttering was caused by the Simconnect server itself, and it looked like it was "caused" by Couatl or GSX (it wasn't), just because it had to connect to an already overcrowded Simconnect server and the server part, being a .DLL that run in-process, CAN slow down the sim. Couatl, being an .EXE, cannot, unless one has set a very wrong (non default) Affinity setting which would work against the work done by the OS to assign spare cores between background applications.