Jump to content

Sign in to follow this  
Ray Proudfoot

Stutters - CPU0 okay but not others. How to fix?

Recommended Posts

1 hour ago, Bert Pieke said:

It is not only what "comes into view" that gets loaded.. it is all the traffic/scenery/etc within a 20nm radius or so..

Understood. Seems a very inefficient method but then again we’re talking about a process around 15 or more years old. Looking at the graphs for the other cores it seems to me that small changes should fix it.

1 hour ago, lownslo said:

Do you use FFTF Dynamic ?  It will help make even "fairly busy" airports more pleasant.

Also, did you try an AM of 4052 rather than 1013 (and run your addons on Logical Processors 0 and 1)?  I agree with Bob... I've tested my 8086K extensively with HT ON (I paid for the feature, and I wouldn't mind using it) but I prefer how the CPU performs with HT OFF.

Greg

No. I’ve tried these utilities in the past and they didn’t make that much difference. The computer was built specifically for flight simulator and I have already asked Chillblast about disabling HT and they advised against it.

Look at those peaks on cores 4-9. They're not continuous. I’m sure a small reduction in scenery settings will lower them. All I need is for them to peak at 99% or lower.

I’m not sure what you mean by “more pleasant. My fps is already locked at 30.


Ray (Cheshire, England).
System: P3D v4.5, Intel i7-8086K o/c to 4.6Ghz, Nvidia GTX 1080 Ti 11Gb, Samsung 970 EVO M.2 SSD, 1Tb Samsung 860 EVO SSD, Asus Prime Z370-A mobo, 32Gb G.Skill DDR4 3000Mhz RAM, Win 10 Pro 64-bit, BenQ PD3200U 32” UHD monitor.
Cheadle Hulme Weather

Share this post


Link to post
Posted (edited)

This is what I've done this morning. Firstly, enabled cores 10 and 11. I've taken off from Paphos, Cyprus and headed south to detemine how much CPU time is being taken by processing scenery etc and how much with the cockpit instruments.

Here are two graphs showing the Learjet 25 by XP and a Carenado PC12. No spiking in the Lear graph but it was happening despite scenery levels being way below usual. This leaves me to believe that cockpit instrument processing is responsible for many of these spikes and that cannot be changed by changing scenery levels most of which is processed by the GPU in any case.

I think it's down to how well (or not) P3D is interacting with the CPU. Only L-M can change that. I'll keep things at reasonable levels and not worry about it.

Here's the Lear usage...

Lear_Ocean.jpg?dl=0

And here's the PC12...

PC12_Ocean.jpg?dl=0

Edited by Ray Proudfoot
Spelling

Ray (Cheshire, England).
System: P3D v4.5, Intel i7-8086K o/c to 4.6Ghz, Nvidia GTX 1080 Ti 11Gb, Samsung 970 EVO M.2 SSD, 1Tb Samsung 860 EVO SSD, Asus Prime Z370-A mobo, 32Gb G.Skill DDR4 3000Mhz RAM, Win 10 Pro 64-bit, BenQ PD3200U 32” UHD monitor.
Cheadle Hulme Weather

Share this post


Link to post

Hi Ray, just done a test with excluding core 1 on my (old) I7 4770 8 core (HT enabled) and I got some stutters. ( I run on the first six cores)

My understanding from the old fsx days that Core 0 was for fibers, core 1 was responsible for the main Scheduler, and cores 2&3 are responsible for the texture management and object batching and Autogen.

Not with standing that LM have moved on from the old FSX model but it may be that the concept is still apparent it may be worth  trying running on the first 6 cores.

bob

 

Share this post


Link to post

Hi Bob,

The i7-4770K was in my previous computer bought in 2013 and sold in late 2018. It has 8 cores compared to 12 on my i7-8086K. Also, L-M have made big changes to how things are handled in P3D compared to FSX so using fewer cores wouldn't help things I think.

On a flight from Liverpool down to Jersey (both UK2000) I experimented by changing some graphics settings. Even with all Scenery Object settings reduced to minimum there was still plenty of activity on cores 4-11 at cruise (FL410). I then changed LOD Radius from Ultra to High and that does appear to have reduced the number of spikes. I'll leave it at HIgh for a few flights.

It's interesting to see how processing just dies away after landing. Okay, Jersey is not the busiest airport but the change was dramatic. So at the moment LOD appears to have a significant impact on CPU processing.

  • Like 1

Ray (Cheshire, England).
System: P3D v4.5, Intel i7-8086K o/c to 4.6Ghz, Nvidia GTX 1080 Ti 11Gb, Samsung 970 EVO M.2 SSD, 1Tb Samsung 860 EVO SSD, Asus Prime Z370-A mobo, 32Gb G.Skill DDR4 3000Mhz RAM, Win 10 Pro 64-bit, BenQ PD3200U 32” UHD monitor.
Cheadle Hulme Weather

Share this post


Link to post

I would certainly once run a test where you assign your P3D main thread ONLY the "real" cores. Is there any specific reason behind your setup with "0,2,4,5,6,7,8 and 9", resulting in a maybe not so ideal mix of "real" and "hyperthreaded" cores?

My suggestion: limit P3D to Core0, Core2, Core4, Core6, Core8 and Core10. Six cores, just as if you turn HT off. Then just make sure that all addons you can assign cores to do not use Core0 or Core1. Usually, for most addons, two cores and their hyperthreaded cores are sufficient, I limited all my addons to Core8, Core9, Core10 and Core11 and I have good results with almost no stutter.

  • Like 1

Greetings, Chris

Intel i7-8700K@5.0GHz, 2x16GB 3200MHz CL14 RAM, Gigabyte AORUS 1080Ti, Windows 10 Home 64bit, Prepar3D 4.5

Share this post


Link to post

Thanks Chris. Logically using fewer cores wouldn't improve things but this flight did appear more or less stutter-free. Just a few when banking hard left after taking off from Brussels 07L back to Liverpool. A few on the ground at EGGP but no cores were stressed so that was odd.

Here's a screenshot showing my position over Basildon, Essex with London below and 100 Ai in P3D. As you can see plenty of reserve in cpu0 but it is frustrating that the load on the others cannot be more venly shared out.

Maybe v5 will bring improvements but for now I'll have a few more test flights with your sugggested cores. All my addons - LNM, EFB Server, ASP3D were assigned to core11 which had plenty in reserve.

Lear_OverLondon.jpg?dl=0


Ray (Cheshire, England).
System: P3D v4.5, Intel i7-8086K o/c to 4.6Ghz, Nvidia GTX 1080 Ti 11Gb, Samsung 970 EVO M.2 SSD, 1Tb Samsung 860 EVO SSD, Asus Prime Z370-A mobo, 32Gb G.Skill DDR4 3000Mhz RAM, Win 10 Pro 64-bit, BenQ PD3200U 32” UHD monitor.
Cheadle Hulme Weather

Share this post


Link to post

With HT enabled it is better to think of logical processors (LP) than cores. If one LP of a core is at 100% then that core is at 100%. So that's 6 cores with 2 LPs each or 12 LPs.

HT is the optimisation of a core.

You can use both LPs of the later cores which will load faster like so: 01,11,11,11,01,01. that's 0,2,4,5,6,7,8,9,10 P3D will use those HT pairs to split the background tasks and reduce the scenario loading time. However a bigger draw on the system can pull resources from the main task.

Remember that the more CPU you use for P3D the less CPU the system has at the critical point of loading new scenery.

  • Like 1

Steve Waite: Engineer at codelegend.com

Share this post


Link to post

Thanks Steve. I’d forgotten about the extra loading time with fewer LPs assigned to P3D. What you say makes it impossible for two LPs on the same core to both run at 100%. Would there be any advantage to each running at 50%? That’s assuming LM would change things. I guess not as they would have done it already. Ignore that. Just me thinking out loud. 🤔

So it seems we can have a smoother sim but the penalty is slower loading times. Or quicker loading times but more stutters. Of the two scenarios today’s seemed better but a few more flights should confirm that one way or another.

  • Like 1

Ray (Cheshire, England).
System: P3D v4.5, Intel i7-8086K o/c to 4.6Ghz, Nvidia GTX 1080 Ti 11Gb, Samsung 970 EVO M.2 SSD, 1Tb Samsung 860 EVO SSD, Asus Prime Z370-A mobo, 32Gb G.Skill DDR4 3000Mhz RAM, Win 10 Pro 64-bit, BenQ PD3200U 32” UHD monitor.
Cheadle Hulme Weather

Share this post


Link to post

With the background tasks you can split those over the two LPs and they can utilise the HT optimisations. Two can share a core at 50% each and they  finish sooner than one at 100%

The main task on LP0 is different, we must forgo the ability to optimise that core with HT because we leave the main task alone on one LP of the core LP0 so as to avoid sharing.

A problem eventually emerges whereby the LP1 will start to show activity gravitating there from system resources. Watch LP1. That's why we leave a core or LP free (core 5 or LP11). We get the same problem with HT disabled but is harder to spot because the activity is merged in the other task.

 

  • Upvote 1

Steve Waite: Engineer at codelegend.com

Share this post


Link to post

...With the background task you must think in terms of granularity - loading hundreds of files that can be split over many cores or LPs as we have got, more or less. So more cores reduces the loading time we see that with a stopwatch. Remember that the system can only supply data at a certain rate so the more cores or LPs must be doing the extra work.

With the foreground task that's not granular in the same way. We can't split down the foreground task so we only allow one LP of that core.

(P3D can accept an AM with 31 binary digits. When moving too fast for the sim to keep up, some stalling can occur in the autogen if your AM does not include LP0.)

  • Upvote 1

Steve Waite: Engineer at codelegend.com

Share this post


Link to post

Food for thought, thanks Steve.👍

  • Like 1

Ray (Cheshire, England).
System: P3D v4.5, Intel i7-8086K o/c to 4.6Ghz, Nvidia GTX 1080 Ti 11Gb, Samsung 970 EVO M.2 SSD, 1Tb Samsung 860 EVO SSD, Asus Prime Z370-A mobo, 32Gb G.Skill DDR4 3000Mhz RAM, Win 10 Pro 64-bit, BenQ PD3200U 32” UHD monitor.
Cheadle Hulme Weather

Share this post


Link to post

You're welcome Ray. There's not a lot to be had with getting it sorted out just right in the AM department so long as with HT enabled, you don't share the first core (11,11,11,11,11,01 will load the quickest and preserve the main task). It is a little more than we would normally get with no AM or HT disabled. It can make the difference on some systems. Every system and setup is different so it's not easy to predict the outcome. P3D is a bit different to general games since it calls on system resources which we must also allow for. Those resources are mostly used when the scenery comes into view and at the same time P3D does as much work on those as it can. So a battle commences to work concurrently without disturbing the timeliness of the main task. Linking more background work done can reduce the fps a little, so fps is not a good gauge of performance with respect to the background task.


Steve Waite: Engineer at codelegend.com

Share this post


Link to post
5 hours ago, Ray Proudfoot said:

I then changed LOD Radius from Ultra to High and that does appear to have reduced the number of spikes. I'll leave it at HIgh for a few flights.

It's interesting to see how processing just dies away after landing. Okay, Jersey is not the busiest airport but the change was dramatic. So at the moment LOD appears to have a significant impact on CPU processing.

My "London" and "London Night" performance profiles have LOD at "Medium" (!).  London Night in particular is pretty draconian, but it allows me to fly into a place like London City with a minimum of stutters and with frame rate hitting my vsync 30, or pretty close to it.

I do not have Orbx TrueEarth Great Britain South.  Maybe if I had that, I would have more issues.


Rhett

i7-8700k @ 5.0 ghz, 32 GB G.Skill TridentZ, 1080Ti, 32" BenQ, 4K res

Share this post


Link to post
30 minutes ago, SteveW said:

...With the background task you must think in terms of granularity - loading hundreds of files that can be split over many cores or LPs as we have got, more or less. So more cores reduces the loading time we see that with a stopwatch. Remember that the system can only supply data at a certain rate so the more cores or LPs must be doing the extra work.

Steve, are you talking about the initial loading time only? That’s the time from double-clicking the shortcut to the Scenario window being displayed and then again after choosing aircraft, airport etc when clicking OK to when the sim fully loads?

If so, I’m happy for that to take longer if it means smoother flights as I have other things to do whilst that process in running. I guess you don’t mean longer loading times for scenery moving into view. Or do you? Surely not as there are minimal stutters.


Ray (Cheshire, England).
System: P3D v4.5, Intel i7-8086K o/c to 4.6Ghz, Nvidia GTX 1080 Ti 11Gb, Samsung 970 EVO M.2 SSD, 1Tb Samsung 860 EVO SSD, Asus Prime Z370-A mobo, 32Gb G.Skill DDR4 3000Mhz RAM, Win 10 Pro 64-bit, BenQ PD3200U 32” UHD monitor.
Cheadle Hulme Weather

Share this post


Link to post
3 minutes ago, Ray Proudfoot said:

Steve, are you talking about the initial loading time only?

You can measure the initial loading time and that performance is reflected throughout the running of the sim. If it loads a scenario faster, it loads additional scenery and planes faster during the simulation as well. However, as I said, the fastest loading does not always add up to the best simulation smoothness so you are looking for balance.


Steve Waite: Engineer at codelegend.com

Share this post


Link to post

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this  
  • Tom Allensworth,
    Founder of AVSIM Online


  • Flight Simulation's Premier Resource!

    AVSIM is a free service to the flight simulation community. AVSIM is staffed completely by volunteers and all funds donated to AVSIM go directly back to supporting the community. Your donation here helps to pay our bandwidth costs, emergency funding, and other general costs that crop up from time to time. Thank you for your support!

    Click here for more information and to see all donations year to date.
  • Donation Goals

    AVSIM's 2020 Fundraising Goal

    Donate to our annual general fundraising goal. This donation keeps our doors open and providing you service 24 x 7 x 365. Your donation here helps to pay our bandwidth costs, emergency funding, and other general costs that crop up from time to time. We reset this goal every new year for the following year's goal.


    10%
    $2,560.00 of $25,000.00 Donate Now
×
×
  • Create New...