Jump to content

P3Dv4 Cologne Bonn - very bad Performance and stutters


winstonwolf

Recommended Posts

At the Moment Windows Installation and the newest Driver Installation is finished .

 

Windows Version : 1809 Build 17763.107

Grafík Driver : Nvidia 416.94

No Tweaks

No Nvidia Settings .

 

Next Stepp - Default Installation of P3Dv4

 

Then Installation of only EDDK .

 

Bring the Results soon.

 

 

Link to comment
Share on other sites

  • Replies 82
  • Created
  • Last Reply

So ,

After some Test , only with EDDK i observe also Mikrostutters , not so many and not so Long as before but they are there .

 

Here a Screenshot with the Performance Data

Please login to display this image.

Link to comment
Share on other sites

Of course, now that he reports to have the stutters also on a blank P3D with only EDDK installed, it is a problem of a to narrow look... sorry guys, but seriously? Again: those stutters occur only on EDDK whereas on other heavy sceneries, the stutters are not present. Means: something with EDDK is causing those stutters. If it would be something related to the disk, drives, system per se, one could observe the same stutters on other heavy scenarios where we even have lower FPS than on EDDK. If this is a misjudgment, I wonder why Mathijs keeps bringing up FPS as an argument if FPS are lower on several heavy sceneries (in my case) like LSZH, EDDF, LEMD, LEBL and others but WITHOUT those stutters...

Link to comment
Share on other sites

  • Aerosoft

We'll discuss this with Lockheed. As we only use 100% standard SDK technics there seems to be some issue with the compiler and/or the sim that clashes with your setup and not with others. There simply is nothing that we know of you can insert in a scenery that could cause these effects and we simply do not see it on our machines. Microstutters are not caused by an error in a scenery, but by a buffer or path being temporarily blocked

 

Can I also kindly advise you to reread some of my comments? That might explain why this happens on your machine with this scenery and not others. This scenery uses some new technology provided by the latest versions of the sim. As these are new modules in the sim, they might affect different systems differently. 

Link to comment
Share on other sites

At a first look i would say he overloads his GPU with frames unlimited, that should be set according to his monitor capabilities. An for his CPU he should use an AM-Setting to get P3D off his virtual core 1 so the main thread can use core 0. 

Link to comment
Share on other sites

3 minutes ago, mlinecker said:

At a first look i would say he overloads his GPU with frames unlimited, that should be set according to his monitor capabilities. An for his CPU he should use an AM-Setting to get P3D off his virtual core 1 so the main thread can use core 0. 

 

I'm afraid i have to strongly disagee with this. Of the 7 systems I setup and a few hundred I've help with, running unlimited frames with Vsync on and triple buffering was far superior than limiting the frames in O3D. There are always exceptions, but overall that seems to be best. Also, no tweaks unless there is a specific reason for doing so.

 

 

Link to comment
Share on other sites

1 hour ago, Mathijs Kok said:

There simply is nothing that we know of you can insert in a scenery that could cause these effects and we simply do not see it on our machines. Microstutters are not caused by an error in a scenery, but by a buffer or path being temporarily blocked

 

Sorry Mathijs, but obviously Oliver and Jo have at least something in mind that could possibly be related to the stuttering and is fixable, otherwise Oliver would not have posted this. Ergo: it IS POSSIBLE to do something about.

 

Besides that, I agree that the stuttering might not be due to an ERROR, but obviously it is still related to the scenery product. And again, what does it help if it is not happening on your systems? Nothing. Also your statement regarding numbers of reports is just... well, almost an affront in a support forum. All I can say with my many years of experience in other support forums of games that are actually sold about hundred times (or even thousand times) more often than the EDDK scenery, never ever one of the moderators there dared to say "if only 22 people are reporting this and we can not recreate the issue, it is considered not being a bug of our product, otherwise the forum will be full of reports". This is just... I am not allowed to write this here... And honestly, I do not understand why you come to such a conclusion.

Link to comment
Share on other sites

vor 24 Minuten, DaveCT2003 sagte:

Of the 7 systems I setup and a few hundred I've help with, running unlimited frames with Vsync on and triple buffering was far superior than limiting the frames in O3D.

 

That depends heavily on his monitor frequency. His GPU is on 100% because of the unlimited frames (calculating picture as many as it can, even when these frames are not used in the end, and thats wasting GPU power).

Link to comment
Share on other sites

vor 6 Minuten, mlinecker sagte:

 

That depends heavily on his monitor frequency. His GPU is on 100% because of the unlimited frames (calculating picture as many as it can, even when these frames are not used in the end, and thats wasting GPU power).

 

Hello , 

My Monitor Frequency is 60Hz . 

What itry till now is to set via Nvidia Inspector the FPS on 30 , Trippelbuffering On , Vsync On Half refresh rate . 

 

Link to comment
Share on other sites

  • Developer
2 hours ago, Querer said:

 

Sorry Mathijs, but obviously Oliver and Jo have at least something in mind that could possibly be related to the stuttering and is fixable, otherwise Oliver would not have posted this. Ergo: it IS POSSIBLE to do something about.

 

Besides that, I agree that the stuttering might not be due to an ERROR, but obviously it is still related to the scenery product. And again, what does it help if it is not happening on your systems? Nothing. Also your statement regarding numbers of reports is just... well, almost an affront in a support forum. All I can say with my many years of experience in other support forums of games that are actually sold about hundred times (or even thousand times) more often than the EDDK scenery, never ever one of the moderators there dared to say "if only 22 people are reporting this and we can not recreate the issue, it is considered not being a bug of our product, otherwise the forum will be full of reports". This is just... I am not allowed to write this here... And honestly, I do not understand why you come to such a conclusion.

 

Totally agree here. The stutters are not a bug generated by buggy code, it is not generated because of non SDK conform Code and it is not generated by any other addon (in most cases).

 

It is possible, that the type of hardware or it‘s drivers has an effect and show the issue more or less, but I don’t get any parameters to change to optimize the settings (drivers/cfgs) to change the situation.

 

But, in difference to Mathijs, I see the issue since existence of the new P3D engine with all (more the 20) scenery addons ( all Professional products which I optimized for the new Plattform,  EDDK is the only one I was not involved yet) before I start to change the form the MDL and XML data compiled in the BGL to get the best results how the engine of P3D V4 can handle it. The feedback here and of 1000end of user shows me, that the way was correct.

There is no statement for this in the SDK, it is a result of 100rd of hours testing.

I could not yet say, if the high detailed Objects of EDDK can be optimized the same way, but there is potential to test it. Jo will provide me the Data based on this knowledge next week, then we will see how far get it.

As I can reproduce the issue on my PC‘s, which are free of any tweeks, overclockings or shader changes, I will be able to see, if the different form to build the BGL data used in all other Professional Sceneries will help for EDDK too.

Until Jo and I have not finished this process, any statement about the reason for this issue are only speculation.

Link to comment
Share on other sites

5 hours ago, winstonwolf said:

What itry till now is to set via Nvidia Inspector the FPS on 30 , Trippelbuffering On , Vsync On Half refresh rate . 

 

I would try setting all of those in the P3D, not NVIDIA Inspector.

 

Best wishes!

 

 

Link to comment
Share on other sites

Hello , 

After fresh Installation of Windows and P3Dv4 inkl. Cologne Bonn . Here some Screenshots from Disk Usage and CPU Usage while over flying the Airport . 

 

My P3Dv4 Installation is on an Samsung MZ-V7P1T0BW 970 PRO Internal  SSD 1TB NVMe M.2 . This is an PCi SSD . 

This SSD is installed dirct on the PCI Port on the Mainboard . 

 

On the Screenshots , this is Drive E: 

 

Can it be that there is an Problem with this Drive ? 

 

Thanks 

Michael 

 

Please login to display this image.

Please login to display this image.

Link to comment
Share on other sites

Here an Perfomance Benchmark between an normal 250GB SSD SATA and my VNAND PCi 1TB SSD on which my P3Dv4 is installed. 

Is it normal that the 1TB PCI SSD have the half of the Speed from an normal SATA 250 SSD . Can it be the reason for the Stutters ?

Thanks 

 

Please login to display this image.

Please login to display this image.

Link to comment
Share on other sites

EDDK is a wonderful airport. At my PC I can't see stuttering in the usual way of this word but another kind of performance issues. I would call it slippering. I can't describe it exactly in English what I mean. In German I would say: "ein Rutschen, ein Gleiten, ein Verzögern des Ablaufes für eine Sekunde (so eine Art Zeitlupe) und dann rutscht der Ablauf etwas schneller weiter, um wieder da zu sein, wo er linear zu der Zeit hätte sein sollen."

This phenomen I encountered at several airports in P3Dv4. It wass EPKK from Flydesign (very strong slippering) and some airports from Simmershome; not as strong as EPKK. Both of them are made with the SDK of P3Dv4; these are the statements from the developers and I believe them. So maybe in EDDK we have the same phenomen?

EPKK is very prominent for me, because at first I used the version from Flydesign (with these slipperings) but as soon as Stanislaus from Drzewiecki had released his version 2.1 for P3Dv4 I switched my installed scenery to his release. What should I say: the same airport with nearly the same buildings, just another developer and a difference like day and night!

So I would agree with Oliver: the techniques behind programming and compiling is not only black and white but depending on other factors which can be discovered only by trialing and testing.

 

mfg Kai

Link to comment
Share on other sites

vor 4 Minuten, Kai-Uwe sagte:

EDDK is a wonderful airport. At my PC I can't see stuttering in the usual way of this word but another kind of performance issues. I would call it slippering. I can't describe it exactly in English what I mean. In German I would say: "ein Rutschen, ein Gleiten, ein Verzögern des Ablaufes für eine Sekunde (so eine Art Zeitlupe) und dann rutscht der Ablauf etwas schneller weiter, um wieder da zu sein, wo er linear zu der Zeit hätte sein sollen."

I just completed my first flight inbound to EDDK and I can confirm this issue. I meanwhile turned the shadows off, only this way I can get >30 FPS with my 3 views setup in EDDK. On ground at terminal 2 I have solid 33 FPS with 2% variance. But when in flight close to the airport I get this behavior as described. FPS are generally around 30 but drop every 2 seconds to around 10-20 and of course the variance is much higher. So far I only noticed it at EDDK.

And again: A very great and beautiful scenery. I flew a leg yesterday on my old FS PC and seeing the old EDDK and new EDDK in comparision, I can't find enough words :-)

Link to comment
Share on other sites

One thing missing from the data up-thread is the GPU load when these stutters occur.  I suspect that this is actually not a GPU issue and that GPU loads during these stutters aren't hitting the trouble zone (>85% GPU load).  But nobody has shown that data in this discussion.

 

winstonwolf's graphs above show that the combination of the CPU main thread on logical processor (LP) 0 and whatever is running on LP1 are maxxing out the first physical core (Core 0).  Remember that on an HT-enabled CPU, both LP0 and LP1 share that first physical core, so if the combined load across the two LPs is at or above 100%, the threads running on those LPs are slowed down considerably as the physical core swaps between the LPs and splits its processing time.  The thing to try here is to set an affinity mask that reserves the first core for the P3D main thread only, and I also do that for the rendering threads running on Core 1.  So for a hexacore CPU with HT enabled, that means setting an affinity mask of 4085 (111111110101).  It doesn't cost anything to try this.  It might also be worth trying with HT off (no AM required in that case).

 

Also, since it appears the CPU is getting hit hard at EDDK (something that also happens under other heavy scenery/autogen loads such as with some ORBX regions), setting a low value for FiberFrameTimeFraction (default is 0.33) will give the main thread some more processing time, at the expense of terrain/texture loading, to process the heavy load.  I use a Dynamic FFTF utility to progressively drop my FFTF from 0.33 down to 0.01 as the altitude drops below 3000 ft AGL.  But to see if this could help, you can just set a lower static FFTF value in the Prepar3D.cfg file and see if it helps with the stutters.  Again, it costs nothing to try.  There is need for some balance, as setting it too low can cause blurries, hence my choice to use the utility to start dropping the FFTF as I get lower in altitude and my visibility range to the horizon starts shrinking.  Low FFTF values give more CPU time to the main thread and less to terrain/texture loading.

 

If reduction of CPU loads using either of these methods helps, consider reducing autogen settings as another alternative, as well as AI traffic load, as these all together contribute to high CPU loads, and when the core running the main thread starts bumping against the 100% wall, stuttering is likely soon to follow.

 

Regards

 

Bob Scott

Link to comment
Share on other sites

I made a promise last week to get the scenery and take a look.  Runs perfectly fine on my rig.

 

i7-4700K O/C at 4.3GHz

16GB RAM

GTX 1080 (Stock settings) pushing one 55-ich 4K and three 23-inch 1080p monitors.

SSD

 

My tests including several weather patterns at the airport, night and daytime.

 

Best wishes.

 

 

Link to comment
Share on other sites

  • 3 weeks later...

So- After somne Weeks and different Settings . 

With an new Graphic Card . GTX 2080 . 

The same - also with low settings . Stutters , Stutters , Stutters . 

It was after an fresh Installation again . 

The same as above . Like an Rubber Band. 

 

When comes an Update for this behavior ? 

 

And onesmore . No Problems on other Airports . 

 

Michael 

Link to comment
Share on other sites

I'm afraid this won't be updateable. It is the way this addon is written. As I told, some further airports exists with the same matter. If you are able to do please test EPKK from FlyDesign. Here you can find exact the same behaviour like to be seen in EDDK.

 

mfg Kai

Link to comment
Share on other sites

I also did some more tests as I'm almost finished with my new FS PC (i7 8086K at 5 GHz and Asus ROG Strix GTX1070 OC). I got now a smooth 30 FPS experience with very good graphics and 3 monitors at almost every airport, except RCTP and EDDK.

EDDK and RCTP have the same issue, just that at RCTP I only have 50% of the severity I got at EDDK.

 

I found out that on my PC it's a GPU issue. I turned shadows off and turned all options to the left in the config tool, only for a test (usually I have shadows on). The GPU is usually around 40% load but every few seconds I get a peak. For that test case, the peak is between 80 and 99%, when I get a longer 99% peak I can see the described stuttering. When I now increase the load on the GPU, hence turning options back on or enabling shadows, the peaks stay way longer at 99% and I get a more severe stuttering. When I disable the side views and only have one view active I can see the same behavior. I then have an base load of around 15% and peaks of around 45%. As there is enough load left, I get no stutters.

 

So when I look at benchmarks of better cards than my overclocked 1070, I think even the best card will cause stuttering as the peak load is so extremely high with let's say a base load of 80% that no card can handle this. In my view there is no real "error" in the scenery but (as already described) some technique internally causes this. And it is not acceptable that even we guys with high end PCs get this severe stuttering. I'm hoping the pending update solves this.

 

Chris

Link to comment
Share on other sites

Archived

This topic is now archived and is closed to further replies.


×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue. Privacy Policy & Terms of Use