At what timestamp in the Q&A are they talking about it?
Okay I found it in the stream.
The non-updated bug list is visible at 51 minutes.
From 1h 10 minutes on they are talking about the fact that SU9 will be focused on stability issues and at 1h 12minutes they are talking about this issue (long-haul performance) specifically:
Some quotes: âit takes a lot of time to reproduce the issueâ and they are âstuggling to try to reprodue thatâ. So imho that does not make it entirely clear wheater the are able to trigger the bug but not pin it to a set of circumstances or if they are not able to reproduce it at all (and is probably also the reason why conflicting statements about this has been made by other posters further up about them being able to reproduce it or not).
Another interesting thing that Jorg Neumann says at 1h 15m (not directly in the context of the long-haul performance issues) is that they have ânearly 50 testers NOWâ. The way he words it makes it very likely that this means the number of testers has been increased recently, which is good news.
So I think bottom line is that we have to wait for SU9 but we can help them with systematic testing (which is difficult oviously since as someon mentioned above, no one who does not have the issue is willing to partake (canât blame them on that obviously, but still makes it harder)).
1 Like
Oh and another thing from the stream that is good news: they seem to be making good progress on directX12.
Official and native DirectX12 support would be great news for performance (current directX12 is a drop in replacement of 11).
Why native DirectX12 could be nice:
- lower level of hardware abstraction possible
- directx12 is almost purely asynchronous and makes it much easier (from what I understand) to multi-thread stuff. Since the issue with long-haul performance seems to be that some components (sometimes the web assembly modules, sometimes other stuff) slow down the main thread, doing more things asynchronous could be possibly the (only/best/easiest) way to fix this issue and other performance issues sustainably.
1 Like
an easy way to see how many experienced pilots have this problem is to look at the log books and see how many failed flights (take off but no landing) after two hours or more.
1 Like
Yes ProSim A320 VNAV works perfectly , at 1500 EUR price tag thatâs to be expected 
ProSim A320 works competely different the other Planes as it has no virtual cockpit and is targeted at professional hardware CockpitsâŠso the software runs outside of the Sim and injects only into the sim what it needs toâŠfor example the same Prosim Software works with P3D & MSFSâŠin avionic and system depth terms it is lightyears ahead of what FBW A320 has goingâŠ
1 Like
Thank you:)
Ah ok thought so, was just checking that it wasnât simply âfancy displaysâ.
So I assume you are not constrained by the sim then if its runs outside of the sim, you have working terrain radar and weather radar showing.
yes radar and terrain I working as it uses its own database for that as well as all other Avionics âŠyou could say that ProSim A320 uses MSFS as a âworld visualisation toolââŠwhile still being dependant on how the flight model moves through the air for that you still need MSFS to simulate a A320 plane moving through the air âŠfor everything else it pretty does its own thing
1 Like
I mean you get 100% system depth of an A320 with ProSim A320âŠits targeted at the Pro clientele
1 Like
This isnât just related to just flights, we have it when working in devmode/sdk as well. We can get it happening a lot sooner at around 20-40mins. I have forwarded a video on to the dev team with diagnostics showing the issue and the engine swapping in and out of video memory strangely. EG dumping nearly 8Gb of video memory and filling the pipe again when the problem really gets going.
This is a high vertices count airport and takes about 30mins to drop down the FPS. Exit out to the main menu then load back into the sim and it will reset
Seems it is something to do with hardware, driver types (EG it doesnât affect us all), and the way the game handles loading things in and out of video memory or that it that process is being tied up by something else that is starting to take too long and itâs skipping an interrupt call in the loop.
All a bit of educated guesswork on my part but itâs interesting what the video memory metric and the fight between CPU/GPU and whatever is growing linearly causing this issue.
3 Likes
I tried this route using the WT CJ4, not quite an airliner⊠The FPS was okay from takeoff, appropriate for EGLL. I had a major problem when I popped out one of the glass screens. FPS quickly deteriorated to 5 FPS and even lower. Continuing was impossible. I donât know if this is the same problem being discussed here or a separate problem discussed elsewhere.
787-10 + heavy division mod.
Perfect flight without any problems (multiplayer)
MSI PRO Z690 A DDR4, i7 12700K @5.0GHz all P-cores, RTX 3080 (511.23)
1 Like
I have just come back to MSFS after a while and in the hope they had addressed one of the biggest issues this game is suffering from, the FPS drop on long haul flights.
Iâm amazed to see that itâs not been addressed at all.
How does a Company like Asobo completely ignore an issue like this, in preference to dealing with clouds and night lighting. I find it incredible.
Its not an imaginary problem. Itâs not linked to having a sub standard PC ( I have an RTX 3080 , Ryzen 9 chip 64gb Ram ) itâs a software issue, plain and simple.
So once again I will leave it 3 or 4 months and come back and hopefully this company will have sorted this mess of a game out . I mean itâs only been over 2 years now,but sure I letâs have better clouds and pointless addons and ignore that elephant in the room .
6 Likes
^ After 0 hours ^ (40 FPS, 7/16GB used RAM, Mainthread 16 ms)
^ After 12 hours ^ (20 FPS, 14/16GB (+100%) used RAM, Mainthread 35 ms (+120%))
Another test run tonight.
Again, something is happening with CoherentGT, CPU and memory that keeps increasing for no logic reason. Repro rate is no doubt 100% in my case.
This was tested in Niamey (DRRN) with the Boeing 787 (no mods).
I also tested with the C152 :
^ After 0 hours ^ (6/16GB used RAM, Mainthread 11 ms)
^ After 8 hours ^ (8/16GB (+30%) used RAM, Mainthread 18 ms (+60%))
As we can see, even with the C152, there is a memory increase for no apparent reason, and although the performance has not dropped yet, the mainthread is starting to slow down. I think that if I had let it run longer, the mainthread would eventually have been slow enough to notice an FPS drop.
Specs :
i7-4790K @4.00GHz
16GB DDR3 RAM
Samsung 860 EVO 1TB
Asus Intel-LGA1150 Motherboard
RTX 2060 6GB VRAM
1 Like
Yesterday I did my usual flight with the A320 fbw and I had a complete flight (4.5 hrs) with no fpm loss whatever. 55+ fpm start to finish. I was so happy I did another flight of 2.4 hrs last night and again, full performance from start to finish. First time having full performance since I did a sim re-install a few weeks back and I was excited as I thought maybe there had been a fix of some sort quietly done remotely.
Anyway, I have the same 4.5 hrs flight running this morning and sadly itâs back to square one, gone from nearly 60 fpm to 4-9 fpm after 2 hrs approx. My joy was short-lived, lol!
Makes me suspect itâs not my hardware as it performed so beautifully all day yesterday without any changes to settings whatever. Ah well, it was great while it lasted.
1 Like
Seems to be the Manipulators thread again, which is what I have seen when having this issue. This could be a badly coded instrument, possibly an issue with WASM or XML instruments?
Itâs possible that the more complicated the aircraft the quicker this sets in.
1 Like
The âLimited by CoherentGTDrawâ low fps issue is probably a seperate issue from the âLimited by Mainthreadâ low fps issue. I have had the slow CoherentGTDraw (something to do with the UI) issue a lot of times since release but i always have the Main thread issue.
Every testing flight i do eventually ends up with bad performance but it happens at different flight times.
1 Like
Asobo wanted âmore detailsâ on this issue (even though thereâs literally 1500 posts in this topic and there are dozens of other topics, even on other forums). But okay, letâs do that again -
Todayâs flight - LGAV to LOWW. Performance degradation of 6 FPS after 1,5 hour flight. Unstable FPS at cruise level, then significiant degradation upon approach.
GIGABYTE X150-PLUS WS-CF
Intel Xeon E3-1230 v5
GIGABYTE GTX 1660 Super
Screenshot after landing:
Screenshot after starting new flight on same location:
1 Like
maybe the key to getting this fixed (and many other issues) is a more powerful built in FPS tool, that can delve deeper into the cause of the number given in the current implementation.
A profiling aspect, that the user can use.
Yes, Asobo have all the development tools, but may well not see the issues, when in their complex dev mode, (possibly even running a different debug build ), to the release and protected version be are seeing the issues in.
If Asobo cannot reproduce it, are they even using the same setups and software , and Internet connections, that we, the uers are using when we expereince these slow downs.
1 Like