Quote

I also don't understand how their engine gets blamed for performance drops in the sim.  It runs external to the sim, ostensibly placed by the OS onto a lesser-used core on a multi-core CPU like most of us run these days. 

Exactly.

Anybody with a cursory knowledge of how Windows works, should know that a separate .EXE on Windows has the following features:

- It runs in its own entirely separate memory space, so it won't take any memory or other resources away from the sim or any other running app. They all have their own separate memory space so, as long there's enough total memory in the system to run them all at the same time without reverting to virtual memory "swapping", they will all work very fast, without slowing down each other.

- It's an user-space program (not a service, or a driver), so it cannot access the simulator or any other running app memory space, not even theoretically, because Windows prevents two separate processes from sharing memory, unless *both* agree to do that, using special methods. Couatl doesn't even try to do that and, of course, it would require the sim to allow it. Could Couatl crash itself ? Of course it can, like any other application out there, but it surely won't bring the sim down with it, as a .DLL or a .GAU COULD.

- Due to how Windows preemptive multitasking works, even if Couatl took a long time to do something, it couldn't possibly slow down the sim or the whole system because, starting from Windows NT, the OS can reclaim control of the CPU even if an application got stuck or didn't yeld control back to the OS. If Couatl ran under Windows 3.1, then yes, I guess it COULD slow down the sim or the whole system...

- Thanks to how the multi threading scheduler works under Windows, if there's are any "spare" CPU cycles available on one core, the OS will assign the threads belonging to an application to *that* core. If the sim is taking 100% of the first core and 10% of the others, Windows will *never* try to assign Couatl to the 1st core.

When Couatl starts, it does a lot of things, like checking the whole scenery database for changes, so it's quite busy until the usual "Airport cache loaded successfully" message appears, which means Couatl has loaded and GSX and all the other scripts are ready.

This process can take  a minute or so, but in that time, the simulator doesn't stop, and the fps is not any lower, for the precise reason it's an external .EXE so, it's running on a spare unused core and, with the newer CPUs, the number of unused cores is ever increasing, which means it would be best to have as many external .EXEs as possible running, instead of having too many in-process executable, like .DLL and .GAU files. Those CAN slow down the sim, and sometimes they do, for example when initializing the panel, with a visible effect on fps until the message goes away.

 

Quote

I have monitored its CPU usage, and it's fairly trivial.

This is called using a scientific method, instead of believing in ghosts. Bravo.

Edited August 3, 20187 yr by virtuali

4 hours ago, Mitch24 said:

The sceneries pop up, take several minutes to load,

Well there is something seriously wrong with your set up then. My PC is getting up to 7 years old (I72600K) and the only thing newer is my graphics card which is an Asus GTX 970, and all my FSDT airports pop up almost instatly.

Just because you have issues, does not mean everybody else has the same. In all the years I have been using FSDT airports, I have never had an issue.

 

12 hours ago, Rockliffe said:

Virtuali, I have the greatest respect for you as a developer, but I am afraid what you say does not ring true with my experiences and I suspect many others. Of course we can make any scenery or aircraft perform well if we drop the sliders or remove any other third party software. I'm sure KLAX would perform perfectly well if I uninstalled Orbx SOCAL, used default clouds, no weather engine and flew a default 737. With respect, that is not a plausable defence. It's a bit like saying to someone who has just bought a Ferrari and is complaining that it spins off the road in wet conditions that perhaps they should only drive it when the roads are dry!! 😃

4

 So essentially you are saying that performance issues couldn't possibly be from ORBX SoCal, HD clouds, any actual weather, high-end aircraft or any combination of them or the location itself but it's all on FSDT? The likening it to complaining about the Ferrari in the wet made me actually laugh out loud, as the common denominator there just like in FSX and P3d is essentially always user error in it's install or setup.

 From mediocre hardware (originally an i5 2500K to an i7 6700K paired with from a GTX580, 970, 1070, and now 1080ti) spanning FSX to all versions of P3d,  I've never had performance issues directly because on any one scenery add-on. 

 

9 hours ago, virtuali said:

This is called using a scientific method, instead of believing in ghosts. Bravo.  

And it's also what separates opinions from facts.  Bravo 2.  👍

 

Edited August 4, 20187 yr by FalconAF

8 hours ago, Dave_YVR said:

The likening it to complaining about the Ferrari in the wet made me actually laugh out loud

 

I'm pleased my personal opinion gave you so much amusement.

19 hours ago, w6kd said:

I have all of FSDreamteam's sceneries, and nearly all of FlyTampa's.  Love them all.

Spot-on. Me, the same. No qualms.

9 hours ago, Dave_YVR said:

mediocre hardware (originally an i5 2500K

I would not really call that mediocre. I run that chip and my newly-reinstalled sim on another system, runs fine for me.

 

9 hours ago, Dave_YVR said:

 

 From mediocre hardware (originally an i5 2500K to an i7 6700K paired with from a GTX580, 970, 1070, and now 1080ti) spanning FSX to all versions of P3d,

17 minutes ago, vc10man said:

I would not really call that mediocre. I run that chip and my newly-reinstalled sim on another system, runs fine for me.

 

My $3000 hardware upgrade from that level of P3D performance was a worthy investment.  🙂

On 8/3/2018 at 2:24 PM, virtuali said:

Could Couatl crash itself ? Of course it can, like any other application out there, but it surely won't bring the sim down with it, as a .DLL or a .GAU COULD.

Based on this statement I'm looking for ideas on how to resolve the python27.dll located in the FSDT\Addon Manager\Couatl folder bringing down my sim twice in the past four hours, both times well into a flight:

 Couatl.exe 
   3.2.0.3997 
   5b0e87ef 
   python27.dll 
   2.7.13150.1013 
   5922d35a 
   c0000005 
   000e77f0 
   97c 
   01d43bf8613490eb 
   D:\FSDreamteam\Addon Manager\Couatl\Couatl.exe 
   D:\FSDreamteam\Addon Manager\Couatl\python27.dll 
   2776f125-aca7-4667-a3f0-1945a322cac9 

Is there any way to diagnose this faulting module? No other fault time stamps exist in the system event viewer, but both these entries appear at precisely the moments P3d4.3 goes down. I've had other sim crashes that pointed to other faulting items; these today only log the above.

 

Edited August 25, 20187 yr by sddjd

4 hours ago, sddjd said:

Based on this statement I'm looking for ideas on how to resolve the python27.dll located in the FSDT\Addon Manager\Couatl folder bringing down my sim twice in the past four hours, both times well into a flight:

 Couatl.exe 
   3.2.0.3997 
   5b0e87ef 
   python27.dll 
   2.7.13150.1013 
   5922d35a 
   c0000005 
   000e77f0 
   97c 
   01d43bf8613490eb 
   D:\FSDreamteam\Addon Manager\Couatl\Couatl.exe 
   D:\FSDreamteam\Addon Manager\Couatl\python27.dll 
   2776f125-aca7-4667-a3f0-1945a322cac9 

Is there any way to diagnose this faulting module? No other fault time stamps exist in the system event viewer, but both these entries appear at precisely the moments P3d4.3 goes down. I've had other sim crashes that pointed to other faulting items; these today only log the above.

 

you be better off  posting  this  on the fsdt  forum  

Edited August 25, 20187 yr by pete_auau

14 hours ago, sddjd said:

Based on this statement I'm looking for ideas on how to resolve the python27.dll located in the FSDT\Addon Manager\Couatl folder bringing down my sim twice in the past four hours, both times well into a flight:

No, it hasn't.

Fact that you have an error log related to Couatl and your sim crashed, doesn't mean the two are related or that Couatl is what made the sim crash.

When I said a .DLL could crash the sim, I'm referring ONLY to .DLLs (or GAUs) LOADED BY THE SIM, either from the dll.xml file, or as a gauge loaded by an airplane, and they must be proper simulator plugins that are made in a specific way. Python27.DLL, of course, is not something that is loaded by the sim, and it runs in the Couatl memory address space, which is entirely separate from the simulator address space so no, just because you see an error report referring to a .DLL, that doesn't mean "it's a .DLL, so it can crash the sim", because that's not a .DLL the sim could ever load or see.

I can only repeat and confirm that Couat, as an external .EXE CANNOT CRASH THE SIM. This is really not open to debate. It simply doesn't have access to the simulator memory, so it cannot crash it. The only way it could, is if it started the simulator itself, or if it attached to it as a debugger. There are other 3rd party utilities that DO start the sim themselves, but Couatl is not one of them.  Since it doesn't do any of these two, it cannot crash the sim.

What probably happened, instead, is that your sim crashed for OTHER reasons and *because* it crashed, IT MADE Couatl crash, because when the sim crashes, it cannot send the normal command to all open applications to close, so they will probably crash too, since their communication with the sim was cut off in a unclean way.

In addition to that, the latest GSX version doesn't even search for airports while you are flying over 10k feet, which was something that, in presence of corrupted navigation data, could cause the sim crash, but this was NOT "caused by Couatl", it was possibly "caused" by the Addon Manager instead, because that one, as a in-process .DLL, could bring down the sim. Not that it was its fault, of course. The *REAL* cause of that crash was some data corruption in the navigation data, because the Addon Manager wasn't even crashing itself, it was the SIM which crashed (in facilities.dll), following a request from the Addon Manager to read the nearest airports. So, even if it wasn't the Addon Manager's fault (the problem was in the navadata), in order to prevent any issues, the latest GSX doesn't do anything while in flight, not even looking for nearby airports.

So, if your crash happened in flight, this is even further confirmation it wasn't "caused" by Couatl but, instead, the sim MADE Couatl crash, because it crashed for other reasons.

Not that this required any confirmation, because, as I've said, Couatl CANNOT crash the sim but, in case you wouldn't believe me, I added the background information required to let you know how *before* the current GSX version, users could be easily mislead thinking GSX or Couatl "crashed the sim", but now even that small chance, caused by corrupted navdata, is not even possible anymore. Well, unless you do most of you flight below 10k feet...

Of course, if you post this on our forum, we can investigate this further, and I could help you finding the real cause.

Edited August 25, 20187 yr by virtuali

On 8/3/2018 at 7:28 AM, Rockliffe said:

... I'm sure KLAX would perform perfectly well if I uninstalled Orbx SOCAL, used default clouds, no weather engine and flew a default 737. With respect, that is not a plausable defence....😃

I'm certainly no FSDT fan*boy, but blaming them for ORBX Socal's performance shortcomings is asinine. Socal grinds most systems to an immediately unflyable state whether FSDT LAX or anything else is installed or not.

Edited August 25, 20187 yr by ChrisKSDF

On 8/2/2018 at 8:33 PM, Nyxx said:

Out of the two I was go with FlyTampa, there right up there with flightbeam. Corfu and EHAM are masterpieces. Boston is amazing but its not the lightest on FPS.

One of Boston i took.

 

+1 flytampa and flightbeam are creating fantastic airports

++1 looking to acquire FT's Amsterdam next sale