Update 5 High Speed Issue
-
@Cloud:
So this is an FM/AFM issue??
I just tried to reproduce it in the DF module.(Although I highly doubt it’s module related)
I tried with a clean jet and a loaded jet. Angels 16 over 750 Knots and I couldn’t reproduce it!!! I’m on Update 5.
C9
Of course this is AFM related
I told you already that this is a RK4 algorythm convergence issue !!!
And this doesn’t happen on all rigs , this is fps dépendant , hard to track , hard to solve
I’m telling you , no change at all in this area since 4.32 and all versions since had some of this symptom
Could compiler parameters increase the problem ? Don’t know but we will look at it
-
Of course this is AFM related
I told you already that this is a RK4 algorythm convergence issue !!!
I did not see that info about the algorithm!!
Hmm, would have to mess around with vSync to see if I can exceed the FPS, just for sh*t’s and grins.
Tks,
C9
-
Anyone had this wierd looking bug in Update 5?
It never happen before U5.Like Mav-jp said, this has been noted already:
https://www.benchmarksims.org/forum/showthread.php?29674-Flight-model-Overspeed-issue
https://www.benchmarksims.org/forum/showthread.php?29200-Viper-wobbling-at-high-speeds -
@JP:
I fully understand you might be pissed off with people finding this bug after so many updates. But this might be due to the fact that most of us did not have fast PCs sometime ago (myself, for example)?!
But lets try to be constructive and to find a solution, instead of saying to people to run the simplified FM?I do numerical integration on the field of molecular dynamics, chemical kinetics and QM/MM etc for living and use Rugge Kutta, implemented that a few times (Matlab, C++,originC and python) and have faced convergence/truncation/numerical instability problems. Sometimes solution was to go to a different order, without loosing a lot of accuracy, other times the problem was different, connected to some racing conditions inside a simulation loop. If you are willing to share some details that you know (codewise), perhaps some of us can give some fresh thinking on that?!
-
Guys, let Mav-JP alone.
He does not need help to find a solution. Its just a matter of having the time, the priority, and energy to do it.
He has already said he knows what is going on and has an idea why it appears.
Besides he has done far more difficult Falcon code jobs in the past I am sure.Sorry for stepping in here, he does not need that help from me too, but I just wanted to say.
Cheers Obi1
-
Guys, let Mav-JP alone.
He does not need help to find a solution. Its just a matter of having the time, the priority, and energy to do it.What?? Just speaking about it has given him ideas about it. Look at his post #36 in response to something I said.
At the end of his post, thinking out loud he said "Could compiler parameters increase the problem ? Don’t know but we will look at it "
So it’s obvious he’s at least considering possibilities and searching for ideas while reading this thread, and that’s always a good thing.
C9
-
@Cloud:
What?? Just speaking about it has given him ideas about it. Look at his post #36 in response to something I said.
At the end of his post, thinking out loud he said "Could compiler parameters increase the problem ? Don’t know but we will look at it "
So it’s obvious he’s at least considering possibilities and searching for ideas while reading this thread, and that’s always a good thing.
C9
That is more tricky
I already had several fixes for it , the probleme is beeing able to repro on my rig
I might have other ideas though , I will work on it , but TBH this bug is happening in very extreme flight range so it’s not prio 1
-
The conditions under which this bug happens are not known ! >> Therefore is it not possible to reproduce it on PURPOSE.
If it happens again, we have to “record” the conditions and submit these for analysis.
-
@A.S:
The conditions under which this bug happens are not known ! >> Therefore is it not possible to reproduce it on PURPOSE.
If it happens again, we have to “record” the conditions and submit these for analysis.
This is not physics related , conditions will not be visible
I know it is very high speed and high fps
-
Not true… people have “capped” the FPS and still had this bug.
By conditions i meant… in what situations (what module, what theater, what alt, what speed, etc etc). Every DATA, what makes it easier to reproduce it. For YOU.
But if you already KNOW 100% why, and what it is … you should be able to “fix it” without reproducing it on your rig
-
if GPU FPS capped (via nvidiaInspector.exe for example) - does it mean your CPU FPS is capped as well?
Perhaps you need mo-slo or downgrade :mrgreen:
-
if GPU FPS capped (via nvidiaInspector.exe for example) - does it mean your CPU FPS is capped as well?
Perhaps you need mo-slo or downgrade :mrgreen:
I was about to say the same thing.
Don’t know how they capped but underclock the GPU and it’s memory would do the trick.
The thing is I never heard of underclock tools for VGA.Maybe running a second app or VGA bench tool at the same time?
But the man has the code.
Στάλθηκε από το MI 5 μου χρησιμοποιώντας Tapatalk
-
why are you still speaking about VGA Arty?
…just try to open 200 google chrome windows, run hi-res video on background, jam your hi*-tech cooling system with your shorts, turn off turbo and enjoy BMS -
cause u eat memory running all those u mention.
and cpu can be underclocked by bios. -
Anyone had this wierd looking bug in Update 5?
It never happen before U5.What is your CPU? Are you by any chance using the 32-bit BMS version?
Not new, this bug exists since 4.32
RK4 algorythm convergence issue at very high speed on some CPU (fps related bug)
Not related to U5 at all,absolutly zéro change in afm
unless we have several bug reports about it in U5 won’t be fixed
I understand that it’s better to avoid time spend –and-- new regressions for an obscure issue that manifests on some subset of CPU.
Does the code use “denormals are zero” and “flush to zero” now? It’s not of particular relevance to the issue but it’s curious nonetheless.
It’s interesting what you say that some CPUs have no trouble integrating. Is it related to particular extension set, microarchitecture, or…? Are newer generations like Haswell+ or Skylake+ immune to the issue? Frankly I’m a bit surprised numerical stability depends on the CPU in any way. Also I’d expect the 64-bit binary to work better since more vector extensions are supported by all amd64 CPUs.
-
I just wanted to add that I had this issue month ago after an update to the NVIDIA driver. (It was reproducible at high speed every time on my sytem: i5-2500K and GTX 760.)
This thread helped me to eliminate it: https://www.benchmarksims.org/forum/showthread.php?14469-Aircraft-shakes-along-roll-axes-when-traveling-above-Mach&highlight=funky
Stubbies2003’s solution worked for me, I set the “set g_bExportRTTTextures” to 0 in the falcon bms.cfg and the shaking is gone.
How is it related to the video driver and the physics in the sim that’s another question…
-
So this is happening only for nvidia graphic cards?
-
it is unrelated with GPU
I have a good fix candidate for it
3 to 4 weeks
-
This MIGHT BE farfetched… but maybe NOT.
I make music, meaning i use various sound-applications and the ASIO4ALL input driver.
There, i realized, that OVER-CLOCKING the system can in certain cases create “input-lag” in the sound-processing.IF over-clocking (if done not stable) may or may not create also input-lags in joysticks and pedals. ? maybe…i am not sure.
But the thought, that over-clocking may or may not create this “bug” we are speaking about above … came to my mind ???
-
@A.S:
This MIGHT BE farfetched… but maybe NOT.
I make music, meaning i use various sound-applications and the ASIO4ALL input driver.
There, i realized, that OVER-CLOCKING the system can in certain cases create “input-lag” in the sound-processing.IF over-clocking (if done not stable) may or may not create also input-lags in joysticks and pedals. ? maybe…i am not sure.
But the thought, that over-clocking may or may not create this “bug” we are speaking about above … came to my mind ???
doubtful
The bug has been identified clearly as a problem of RK4 scaling at very high speed