Author Topic: couatl.exe cpu usage in the cruise  (Read 2486 times)

sw34669

  • Jr. Member
  • **
  • Posts: 90
couatl.exe cpu usage in the cruise
« on: November 30, 2018, 10:40:25 am »

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

  • Administrator
  • Hero Member
  • *****
  • Posts: 51462
    • VIRTUALI Sagl
Re: couatl.exe cpu usage in the cruise
« Reply #1 on: December 05, 2018, 04:22:51 pm »
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

  • Jr. Member
  • **
  • Posts: 90
Re: couatl.exe cpu usage in the cruise
« Reply #2 on: December 06, 2018, 04:01:32 pm »
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

  • Full Member
  • ***
  • Posts: 211
Re: couatl.exe cpu usage in the cruise
« Reply #3 on: December 06, 2018, 09:19:04 pm »
Quote
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

  • Administrator
  • Hero Member
  • *****
  • Posts: 51462
    • VIRTUALI Sagl
Re: couatl.exe cpu usage in the cruise
« Reply #4 on: December 07, 2018, 01:13:04 pm »
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.