26 minutes ago, Swe_Richard said:

Because it shouldn’t be needed..? Was that your intellectual contribution to the thread? 

Talking about intellectual contribution when stubbornly sticking to a "solution" that is simply almost impossible is a little bit over the top, no? Obviously you have no clue about problem solving strategies, otherwise this resistance to try other, more logical things is not understandable. For this case a joke fits perfectly: a guy trained a spider to jump when he claps. Then he started to remove one leg and clap again. Spider still jumps. Last leg remaining, spider still jumps. After he removed the last leg, the spider did not jump anymore, even after several claps. The guys conclusion: a spider without legs cant hear anything...

Like I said, stubborn smh 

31 minutes ago, AnkH said:

Talking about intellectual contribution when stubbornly sticking to a "solution" that is simply almost impossible is a little bit over the top, no? Obviously you have no clue about problem solving strategies, otherwise this resistance to try other, more logical things is not understandable. For this case a joke fits perfectly: a guy trained a spider to jump when he claps. Then he started to remove one leg and clap again. Spider still jumps. Last leg remaining, spider still jumps. After he removed the last leg, the spider did not jump anymore, even after several claps. The guys conclusion: a spider without legs cant hear anything...

Well. I wouldn’t call it a solution (I actually didn’t) more an interesting find as the effect has been undeniable. I am not ”stubbornly sticking to a solution” at all; this is no solution. The solution would be for Asobo to make sure their program runs on all hardware. Then, to be honest, changing timings should simply not be needed as they have always worked, not only in everything else I do but in MSFS up to right before SU5 as well. If that is stubborn, or as you imply, r3tarded (per your really funny ”joke” about legless spiders) I couldn’t care less even if I wanted to.

Edited August 19, 20214 yr by Swe_Richard

53 minutes ago, OneOfMany said:

What is model of mobo? 

Gigabyte Aorus x570 pro. I think. 

6 minutes ago, Swe_Richard said:

as the effect has been undeniable.

Obviously, you did not get the smallest bit of my post. Over and out here, useless...

Guys, he clearly doesn't want to follow people's advices to solve HIS problem, which would take him a couple minutes, so let him try to fix HIS CTD's by himself. He doesn't deserve any help.

Edited August 19, 20214 yr by Alvega

7 minutes ago, Swe_Richard said:

Well. I wouldn’t call it a solution (I actually didn’t) more an interesting find as the effect has been undeniable. I am not ”stubbornly sticking to a solution” at all; this is no solution. The solution would be for Asobo to make sure their program runs on all hardware. Then, to be honest, changing timings should simply not be needed as they have always worked, not only in everything else I do but in MSFS up to right before SU5 as well. If that is stubborn, or as you imply, r3tarded (per your really funny ”joke” about legless spiders) I couldn’t care less even if I wanted to.

I presume you've made arrangements to ship your machine to Asobo for testing?  Otherwise you're probably dead in the water if you expect the fix to come from them at this point, especially since you seem reluctant to listen to reasonable advice.

Man, this thread really went south. I posted about an interesting find. A find I actually confirmed worked (100% CTD-free versus 100% CTDs doing the same flights under similar conditions although at the same time stating I am not done testing and not knowing if the tree variable is the silver bullet). This made users more or less call me retarded and unable to troubleshoot. Insane. 

14 minutes ago, Swe_Richard said:

Gigabyte Aorus x570 pro. I think. 

i run 3800 mhz fabric 1900 c15 on GA X570 master with G-Skill 3600 C16 should not be any problem

Edited August 19, 20214 yr by westman

23 minutes ago, Swe_Richard said:

Then, to be honest, changing timings should simply not be needed as they have always worked, not only in everything else I do but in MSFS up to right before SU5 as well.

Changing timings shouldn't be needed, but it might still be useful, even if it's just to shut up the crowd that keep telling you to change the timings when you prove them wrong 😉 

I'm not convinced your issue is due to the RAM timings, especially as you never experienced any system freezes / reboots (as far as I understand). On the other hand, RAM issues haven't been unheard of when running tighter timings on x570 boards, although most of the time a bios update could fix them. Software instabilities have always been difficult to track down, and follow a logic that's hard to grasp at times. 

Edited August 19, 20214 yr by pstrub

10 minutes ago, VFXSimmer said:

I presume you've made arrangements to ship your machine to Asobo for testing?  Otherwise you're probably dead in the water if you expect the fix to come from them at this point, especially since you seem reluctant to listen to reasonable advice.

Or, maybe they investigate why their code worked on a certain subset of hardware on SU4 but not SU5? That might be a revolutionary thought for all the analytical experts in here. 

7 minutes ago, pstrub said:

Changing timings shouldn't be needed, but it might still be useful, even if it's just to shut up the crowd that keep telling you to change the timings when you prove them wrong 😉  

I like your way of thinking. 👍

Just now, Swe_Richard said:

Or, maybe they investigate why their code worked on a certain subset of hardware on SU4 but not SU5? That might be a revolutionary thought for all the analytical experts in here. 

Look, if you're content to run your trees at a low setting, then great problem solved.  Your OP was an interesting, albeit pretty unlikely cure.

Others were trying to offer up reasons why that unusual solution worked in your case.  The majority of systems out there dont have the problem you are experiencing or else everyone would be converging on the same solution and the tree fix would have become ubiquitous by now.  Occam's Razor points more to something unique to your setup which is what people were offering up very reasonable theories of how that could be so.

The simple truth is there are far too many hardware configurations out there to expect Asobo to test for them all.  I do find it short-sided that they dont output a crash log somewhere like X-Plane does - would be a great way to both help themselves and the community.  Barring that, I dont think you're going to come to a happy conclusion without doing more leg work on your end.  I understand it's frustrating, but I think thats the reality you're facing.

The initial posts suggesting you try testing your memory clock as a potential reason for why your tree fix worked were very reasonable and no one was trying to insult anyone's intelligence or experience.  I do feel its a bit short-sided on your part, however, to draw an immediate conclusion that because your "other software" (and even SU4) worked at the same clock rate it is therefor not possible for that to be the cause.  Clearly something changed.  As I suggested, SU5 is much more multi-threaded which in and of itself operates your hardware differently.

I humbly suggest that if you ask the community for help, that its not going to do you any favors to be dismissive or belligerent when someone offers reasonable advice.  Otherwise, all you are doing is venting and you'll get no closer to a solution, which I still presume is to get MSFS back and running well on your machine.

 

31 minutes ago, AnkH said:

Obviously, you did not get the smallest bit of my post. Over and out here, useless...

Walt, what? 
As per your own words, my ”solution” (I never named it as such) was impossible even though it clearly was not..? Then you proceeded to insult me? What was that wisdom you tried so hard, alas in vain, to convey to me?

21 minutes ago, pstrub said:

Changing timings shouldn't be needed, but it might still be useful, even if it's just to shut up the crowd that keep telling you to change the timings when you prove them wrong 😉 

I'm not convinced your issue is due to the RAM timings, especially as you never experienced any system freezes / reboots (as far as I understand). On the other hand, RAM issues haven't been unheard of when running tighter timings on x570 boards, although most of the time a bios update could fix them. Software instabilities have always been difficult to track down, and follow a logic that's hard to grasp at times. 

I'd say this is actually a very reasonable statement.  No one is trying to 'prove' anything though - just offering up a theory on how a tree fix could be improving Richard's CTD's.

Memory clock does seem like an unusual cause ... but at the same time, his CTDs in general seem fairly unusual since he's eliminated all of the obvious causes like Community folders, blah blah blah.

Its kind of about the time that I'd be looking for "unusual causes" just to eliminate them as a possibility.  If its a fairly simple thing to test, what's the harm? .. heck you even get an "I told you so" out of the deal if it doesnt fix the problem.