I am still running FSX:SE and have noticed a very frustrating problem with the Connie that I wonder might have been resolved with 64 bit P3D. What I am noticing is that whilst the entire flight (from engine startup, taxi, take-off, climb, cruise, descent and landing) is perfectly fine with perfect frame rates throughout, as soon as the aircraft exits the landing runway and onto the taxiway (but not before - even the final landing rollout is perfect with frame rates), the frame rates then immediately plummet. I mean, really plummet. But if I were to save the flight on final approach, for example and then exit FSX:SE and re-start it, there are no problems whatsoever.
I have 100% elimated overclocking, heat issues, multi-threading (or SMT as it is with Ryzens) "collisions" as the cause and can only think this is either something to do with perhaps some "code" the Connie simulation starts to churn through once it exits the runway at the end of the flight, or perhaps sub-optimal memory or thread management in FSX:SE (which happens after flights an hour or longer and triggered as soon as the aircraft hits the taxiway) that was resolved by the time P3D v4 (64 bit) came out.
The test flights I have used all this last week for testing are KBUF to KJFK and CYQM to KJFK, landing time variously during morning "peak" hours or as dusk is turning into night (where I think the system loads would be the highest.
Now this does happen to a far lesser extent with another high end add-on so that perhaps points to a combination of the Connie's high quality and complexity along with other factors. But since I cannot control that, I am still wondering if there is a deficiency in FSX:SE that was later resolved with 64 bit P3D. So I think perhaps something else must be happening because as I say, if I were to save the flight, say, 10 NM from the destination airport and re-start FSX, I do not have any problems. Which tend to make me think there is some inherent deterioration in FSX performance over time that cannot be shown by any of the usual "diagnostics" such as clock speed, VAS, available memory, heat monitoring, etc.
That said, I have read of P3D v5 users also reporting a drop in performance over time, so maybe whatever causes FSX to do it is still a factor all these years later in P3D.
I would like to buy P3D to experiment with this issue but it would also involve re-buying the Connie, so even with the P3D refund offer, it is an expensive experiment if it yields nothing. I am thus curious as to whether anyone has ever noticed this with P3D - basically a significant drop in frame rates which begins the very moment the sim detects that you have left the runway onto a taxiway after a flight?
Thanks
Question for P3D users - version 4 or higher
-
- Senior Master Sergeant
- Posts: 2439
- Joined: 15 Mar 2016, 08:23
Re: Question for P3D users - version 4 or higher
Hi.
I dont have P3D , i use FSXA , and the airports you mention are the cause in FSXA , as they are high density areas , to get better frames you need to turn your scenery sliders down to a lower setting or go to less dense airport areas , and FSXA does unfortunatly suffer from VAS issues due to 32 bit and max memory limit that was set way to low , to some extent P3D should rectify this , as for KBUF the airport where the connie was built and first flew is close to the high density scenery area of KLAX .
If you have the paid version of FSUIPC then you can set it up to display VAS if flying in windows mode , which in FSXA runs more smoothly and reliably than in full screen mode.
regards Alan.![Cool 8)](./images/smilies/icon_cool.gif)
I dont have P3D , i use FSXA , and the airports you mention are the cause in FSXA , as they are high density areas , to get better frames you need to turn your scenery sliders down to a lower setting or go to less dense airport areas , and FSXA does unfortunatly suffer from VAS issues due to 32 bit and max memory limit that was set way to low , to some extent P3D should rectify this , as for KBUF the airport where the connie was built and first flew is close to the high density scenery area of KLAX .
If you have the paid version of FSUIPC then you can set it up to display VAS if flying in windows mode , which in FSXA runs more smoothly and reliably than in full screen mode.
regards Alan.
![Cool 8)](./images/smilies/icon_cool.gif)
Re: Question for P3D users - version 4 or higher
Well if definitely is not VAS - FSX:SE actually handles all of that extremely well and it is no problem given I do not run complex large add-on airports (only the small ORBX ones which I disable anyway when I am flying airliners and only have enabled when I fly small GA aircraft).
But I think there is definitely a case for the system simply being over-taxed and that is because FSX>P3D is known to be very tough on computing power when (ironically) taxiing around large airports, I looked further into this.
Turns out the stock AI were simply pushing the machine too hard, causing the frame rate to drop below half vsync (running 60 hz monitor frame rate half refresh). As soon as I disabled the airline traffic for testing, the stutters went away when rolling off onto the taxiway all the way to the terminal. Tested it five times on five flights and this as a consistent result.
So out of curiosity I then edited the stock Microsoft traffic file to get rid of everything except the low poly models that Microsoft included (PA-28, Dash 8 and MD 83) and then turned the sliders up to compensate so the same numbers of aircraft were in the vicinity. And all was good. So it is clearly that stock inefficient AI traffic - using (flyable) models that are much more complex than necessary and in addition, just running the AI to begin with takes way more CPU cycles than I gave it credit for.
I guess this is the price we pay for a sim that was written when Microsoft assumed we would end up with dual core processors running at 16 Ghz when what we ended up with was 8 core processors running at 4 Ghz!!
But I think there is definitely a case for the system simply being over-taxed and that is because FSX>P3D is known to be very tough on computing power when (ironically) taxiing around large airports, I looked further into this.
Turns out the stock AI were simply pushing the machine too hard, causing the frame rate to drop below half vsync (running 60 hz monitor frame rate half refresh). As soon as I disabled the airline traffic for testing, the stutters went away when rolling off onto the taxiway all the way to the terminal. Tested it five times on five flights and this as a consistent result.
So out of curiosity I then edited the stock Microsoft traffic file to get rid of everything except the low poly models that Microsoft included (PA-28, Dash 8 and MD 83) and then turned the sliders up to compensate so the same numbers of aircraft were in the vicinity. And all was good. So it is clearly that stock inefficient AI traffic - using (flyable) models that are much more complex than necessary and in addition, just running the AI to begin with takes way more CPU cycles than I gave it credit for.
I guess this is the price we pay for a sim that was written when Microsoft assumed we would end up with dual core processors running at 16 Ghz when what we ended up with was 8 core processors running at 4 Ghz!!
Who is online
Users browsing this forum: No registered users and 10 guests