Jump to content
Sign in to follow this  
SledDriver

P3D multicore usage anomoly

Recommended Posts

The overhead thing - look at it this way. When climbing and perhaps going into a downdraught among the mountains, the climb is reduced or even reversed. We apply more power to keep in the climb. If we are already on full throttles, there's no way to increase climb. When the PC gets that extra complexity in the scene, it can draw on available overhead to keep running smooth.


Steve Waite: Engineer at codelegend.com

Share this post


Link to post
1 hour ago, SteveW said:

I think there is some confusion regarding RTSS.

Basically when using RTSS we often see 100% even when the core is not in full use no matter what you do.

But if you start the sim first then start RTSS sometimes you might get less than 100% showing even though you changed nothing

I looked programmatically at the performance counters in the system running RTSS and P3D. Depending on startup behaviour this setup seems to do different things. It appears to be a wait state doing nothing when there is reserves of throughput. It does nothing.

Set up with VSync=On+Unlimited, then afterwards, apply RTSS after you got all set up with an overhead that can handle the complex peaks in the sim flow.

When we have overhead the CPU and GPU have room, available power, to soak up the fluctuations requiring extra throughput. If there's no more power in hand then when that peak of complexity hits, the sim slows to meet it. Variation in the flow of the sim shows up as micro stutter or long frames. Inability to keep up on the whole gives stutter.

 

Hi Steve,

Is this wait state part of P3D?

Because this behaviour seems to be unique to Prepar3D. In other programs/games RTSS always reduces cpu usage, whether it is started before or after the game doesn't matter.

Share this post


Link to post

It must be unique to P3D V4.x, as it is definitely very easy and predictable to dial back demand w/ a concomitant reduction in CPU utilization on the main thread.


Noel

System:  7800x3D, Thermal Grizzly Kryonaut, Noctua NH-U12A, MSI Pro 650-P WiFi, G.SKILL Ripjaws S5 Series 32GB (2 x 16GB) 288-Pin PC RAM DDR5 6000, WD NVMe 2Tb x 1, Sabrent NVMe 2Tb x 1, RTX 4090 FE, Corsair RM1000W PSU, Win11 Home, LG Ultra Curved Gsync Ultimate 3440x1440, Phanteks Enthoo Pro Case, TCA Boeing Edition Yoke & TQ, Cessna Trim Wheel, RTSS Framerate Limiter w/ Edge Sync for near zero Frame Time Variance achieving ultra-fluid animation at lower frame rates.

Aircraft used in A Pilot's Life V2:  PMDG 738, Aerosoft CRJ700, FBW A320nx, WT 787X

 

Share this post


Link to post
2 hours ago, SteveW said:

The overhead thing - look at it this way. When climbing and perhaps going into a downdraught among the mountains, the climb is reduced or even reversed. We apply more power to keep in the climb. If we are already on full throttles, there's no way to increase climb. When the PC gets that extra complexity in the scene, it can draw on available overhead to keep running smooth.

Hey Steve, do you understand the mechanism by which I get that coveted perfect freedom from micro-stutters using the unlimited/vsync/30Hz, versys how it differs from using RTSS?  IOW, can one get the identical smoothness from RTSS, or is the magic truly unique to the 30Hz method?


Noel

System:  7800x3D, Thermal Grizzly Kryonaut, Noctua NH-U12A, MSI Pro 650-P WiFi, G.SKILL Ripjaws S5 Series 32GB (2 x 16GB) 288-Pin PC RAM DDR5 6000, WD NVMe 2Tb x 1, Sabrent NVMe 2Tb x 1, RTX 4090 FE, Corsair RM1000W PSU, Win11 Home, LG Ultra Curved Gsync Ultimate 3440x1440, Phanteks Enthoo Pro Case, TCA Boeing Edition Yoke & TQ, Cessna Trim Wheel, RTSS Framerate Limiter w/ Edge Sync for near zero Frame Time Variance achieving ultra-fluid animation at lower frame rates.

Aircraft used in A Pilot's Life V2:  PMDG 738, Aerosoft CRJ700, FBW A320nx, WT 787X

 

Share this post


Link to post
1 hour ago, itsjase said:

Hi Steve,

Is this wait state part of P3D?

Because this behaviour seems to be unique to Prepar3D. In other programs/games RTSS always reduces cpu usage, whether it is started before or after the game doesn't matter.

On RTSS. Seems to be to do with the way P3D works since it has multiple screens and undocked panels etc. I've not had time to look into it properly, but it does appear that the sim is limited and the work done is limited in the fashion of VSync=On+Unlimited. When we have overhead set in the system - depending on how things start up it might, or might not, appear to wait in a process using up performance count so that the Task Manager graph shows 100%. Actually it's hovering around 98-100% in the count, fluctuating minutely, in accordance with the frame rate. So there's just a little thing going on that doesn't spoil it. It's likely that P3D is complex enough to be fooled by it.

 

47 minutes ago, Noel said:

Hey Steve, do you understand the mechanism by which I get that coveted perfect freedom from micro-stutters using the unlimited/vsync/30Hz, versys how it differs from using RTSS?  IOW, can one get the identical smoothness from RTSS, or is the magic truly unique to the 30Hz method?

With RTSS you should see a slight improvement, on graph paper, since it uses less resources than the NVidia Control Panel version with preemptive CPU frame timing rather than counting frames on the GPU to see how its doing.

 


Steve Waite: Engineer at codelegend.com

Share this post


Link to post
4 hours ago, SteveW said:

I think there is some confusion regarding RTSS.

Basically when using RTSS we often see 100% even when the core is not in full use no matter what you do.

But if you start the sim first then start RTSS sometimes you might get less than 100% showing even though you changed nothing

I looked programmatically at the performance counters in the system running RTSS and P3D. Depending on startup behaviour this setup seems to do different things. It appears to be a wait state doing nothing when there is reserves of throughput. It does nothing.

Set up with VSync=On+Unlimited, then afterwards, apply RTSS after you got all set up with an overhead that can handle the complex peaks in the sim flow.

When we have overhead the CPU and GPU have room, available power, to soak up the fluctuations requiring extra throughput. If there's no more power in hand then when that peak of complexity hits, the sim slows to meet it. Variation in the flow of the sim shows up as micro stutter or long frames. Inability to keep up on the whole gives stutter.

 

I fully understand the concept and benefit of overhead, but if P3D sets up wait states giving an indication that the P3D main thread is constantly at 100%, even though it may not be, just how are we to know exactly how loaded the core is, and therefore how can we possibly know when we have the sim set up at a suitable load performance for our specific hardware?

I mean, it's gonna show 100% whether it is actually lightly loaded or being pushed past what it can deliver reliably.

So I don't see how we can ever know that we have done a good job configuring the sim. It's all plain guess work. So when the stutters happen, we have no idea why, from what, or how to fix them.

If the sim is going to give a 100% load indication all the time, then we are going to need some much more informative in-sim metering to provide the required feedback to let us configure our sims effectively.

Share this post


Link to post
9 minutes ago, SledDriver said:

but if P3D sets up wait states giving an indication that the P3D main thread is constantly at 100%, even though it may not be, just how are we to know exactly how loaded the core is,

I didn't say that. unfortunately these conversations can get out of hand very easy trying to provide explanation upon explanation.

Check it out: I said that the situation arises when RTSS is running then start P3D, but may not do that when you run P3D then start RTSS and we get to see the relaxed core..

11 minutes ago, SledDriver said:

and therefore how can we possibly know when we have the sim set up at a suitable load performance for our specific hardware?

I mean, it's gonna show 100% whether it is actually lightly loaded or being pushed past what it can deliver reliably.

So I don't see how we can ever know that we have done a good job configuring the sim. It's all plain guess work. So when the stutters happen, we have no idea why, from what, or how to fix them.

So then I said if you set up with:

VSync=On+Unlimited

so that you can see the core is relaxed - now you can set RTSS to do its thang without knowing the outcome.


Steve Waite: Engineer at codelegend.com

Share this post


Link to post
1 hour ago, SteveW said:

 

1 hour ago, SteveW said:

With RTSS you should see a slight improvement, on graph paper, since it uses less resources than the NVidia Control Panel version with preemptive CPU frame timing rather than counting frames on the GPU to see how its doing.

Hmm, I'm not sure that answered my question if you will:  I have perfectly smooth animation now vsyncing to a 30mHz refresh rate set in nV CP's display settings as my screen supports 30Hz.  What I'm curious to know is if RTSS uses a mechanism that can offer the same perfectly smooth animation I have now.  I'm sure they must be using different methods to achieve a frame rate limit of 30, so it's not a given I could expect to see the same quality animation.  I've used other 30fps limiters with much less success so once I found the magic w/ 30Hz the smoothness problem has been solved completely.  For clarity--perfectly smooth video only happens when I have that headroom for the CPU to accommodate those periods of intermittent higher demand.  Because of how I set my scenery sliders and having awareness how much the specific aircraft burdens the total CPU load I most always have sufficient headroom.


Noel

System:  7800x3D, Thermal Grizzly Kryonaut, Noctua NH-U12A, MSI Pro 650-P WiFi, G.SKILL Ripjaws S5 Series 32GB (2 x 16GB) 288-Pin PC RAM DDR5 6000, WD NVMe 2Tb x 1, Sabrent NVMe 2Tb x 1, RTX 4090 FE, Corsair RM1000W PSU, Win11 Home, LG Ultra Curved Gsync Ultimate 3440x1440, Phanteks Enthoo Pro Case, TCA Boeing Edition Yoke & TQ, Cessna Trim Wheel, RTSS Framerate Limiter w/ Edge Sync for near zero Frame Time Variance achieving ultra-fluid animation at lower frame rates.

Aircraft used in A Pilot's Life V2:  PMDG 738, Aerosoft CRJ700, FBW A320nx, WT 787X

 

Share this post


Link to post
3 minutes ago, SteveW said:

I didn't say that. unfortunately these conversations can get out of hand very easy trying to provide explanation upon explanation.

Check it out: I said that the situation arises when RTSS is running then start P3D, but may not do that when you run P3D then start RTSS and we get to see the relaxed core..

So then I said if you set up with:

VSync=On+Unlimited

so that you can see the core is relaxed - now you can set RTSS to do its thang without knowing the outcome.

Ok thanks Steve. I'll do some more tests.

I am somewhat confused at the moment about what is actually going on in this sim. I spent many hours the other day doing controlled tests, and continuously simplified my configuration down to the point where virtually all settings in options where on there lowest, and I was flying a simply plane, yet my CPU continued to show 100% on the main core.

You can see the full report on this earlier in this thread here: 

I'd be interested to know what is going on here.

 

Share this post


Link to post
6 minutes ago, Noel said:

Hmm, I'm not sure that answered my question if you will:  I have perfectly smooth animation now vsyncing to a 30mHz refresh rate set in nV CP's display settings as my screen supports 30Hz.  What I'm curious to know is if RTSS uses a mechanism that can offer the same perfectly smooth animation I have now.  I'm sure they must be using different methods to achieve a frame rate limit of 30, so it's not a given I could expect to see the same quality animation.  I've used other 30fps limiters with much less success so once I found the magic w/ 30Hz the smoothness problem has been solved completely.  For clarity--perfectly smooth video only happens when I have that headroom for the CPU to accommodate those periods of intermittent higher demand.  Because of how I set my scenery sliders and having awareness how much the specific aircraft burdens the total CPU load I most always have sufficient headroom.

That is basically what I said, in that most likely this level of changes are hard to spot exactly but the RTSS method should be as good as if not slightly smoother. So I said on graph paper 🙂

The RTSS mechanism uses less resources so expect an improvement when it is attending to the cap. How much that is not much. The thing is we know that to some extent P3D can become, shall we say confused at this cap and leaves something hanging over doing nothing. The 100% condition arises with the counting of the performance counters and not the use of the core. 

Edited by SteveW

Steve Waite: Engineer at codelegend.com

Share this post


Link to post

I'm also rather interested to know that if there is all this headroom tech going on, then why do we all still suffer from stutters when for instance on finals for a large airport, and it suddenly produces a 2 second stutter when a couple of miles out, even though otherwise the config is perfectly capable of flying over that airport smoothly.

Whatever all this overhead tech is, it obviously doesn't work very well/at all, as we all spend out lives fighting stutters.

Any 'lookahead' overhead tech needs to at least provide a solution to just these sort of issues or it is all BS and worthless.

I can configure my sim so it runs pretty much glassy smooth all the time, but I cannot have any traffic enabled or the stutters return just when I don't want them, like on finals, although I dont want them at all really.

We've been putting up with this nonsense since the days of FSX, and after another decade, the issues still are not resolved. It should not be the job of the sim user to understand all the inner workings of the sim in order to get it running smoothly, especially on powerful modern hardware.

It needs fixing properly.

Share this post


Link to post
Just now, SledDriver said:

I'm also rather interested to know that if there is all this headroom tech going on, then why do we all still suffer from stutters when for instance on finals for a large airport, and it suddenly produces a 2 second stutter when a couple of miles out, even though otherwise the config is perfectly capable of flying over that airport smoothly.

Whatever all this overhead tech is, it obviously doesn't work very well/at all, as we all spend out lives fighting stutters.

Any 'lookahead' overhead tech needs to at least provide a solution to just these sort of issues or it is all BS and worthless.

I can configure my sim so it runs pretty much glassy smooth all the time, but I cannot have any traffic enabled or the stutters return just when I don't want them, like on finals, although I dont want them at all really.

We've been putting up with this nonsense since the days of FSX, and after another decade, the issues still are not resolved. It should not be the job of the sim user to understand all the inner workings of the sim in order to get it running smoothly, especially on powerful modern hardware.

It needs fixing properly.

A two second stutter needs a 27GHz CPU to handle it. lol. Variance in the speed of delivery is what you see especially down at 30Hz or below.

With FSX we could half refresh with fullscreen exclusive mode. On a 60Hz monitor it looked good steered to 30fps (VSync is not a hard cap). But in the desktop window this doesn't work for FSX. With P3D it's only ever a desktop window and so we have the VSync=On setting when used with Unlimited slider 0, we get the GPU steered to the monitor frequency. if that's 60Hz and we want 30 we need to look at options. NCP and RTSS come into play. Or below 30fps try out the Locked slider, that's hard on the system.

 


Steve Waite: Engineer at codelegend.com

Share this post


Link to post
7 minutes ago, SteveW said:

That is basically what I said, in that most likely this level of changes are hard to spot exactly but the RTSS method should be as good as if not slightly smoother. So I said on graph paper 🙂

 

I can't imagine how RTSS could possibly be better because as I say I'm seeing perfect animation already, and I mean that!  Now if you could jack that up to 40 or 50 and maintain this perfect smoothness then yes that would preferred and likely significantly noticeable.  IOW the only deficit I see is just the lower frame rate of 30.  I can see returning the monitor to 60Hz might also offer a different kind of improvement.


Noel

System:  7800x3D, Thermal Grizzly Kryonaut, Noctua NH-U12A, MSI Pro 650-P WiFi, G.SKILL Ripjaws S5 Series 32GB (2 x 16GB) 288-Pin PC RAM DDR5 6000, WD NVMe 2Tb x 1, Sabrent NVMe 2Tb x 1, RTX 4090 FE, Corsair RM1000W PSU, Win11 Home, LG Ultra Curved Gsync Ultimate 3440x1440, Phanteks Enthoo Pro Case, TCA Boeing Edition Yoke & TQ, Cessna Trim Wheel, RTSS Framerate Limiter w/ Edge Sync for near zero Frame Time Variance achieving ultra-fluid animation at lower frame rates.

Aircraft used in A Pilot's Life V2:  PMDG 738, Aerosoft CRJ700, FBW A320nx, WT 787X

 

Share this post


Link to post

The more there is moving around in the scene, the longer it takes to draw them all, the longer a frame takes to draw.

Swing the view around, maybe just in a turn, and the next frame can take twice as long to draw.

So the system requires throughput available to keep that consistent.

If it's at 100% then the simulator slows down as the scene complexity increases, looking back into open sky speeds back up to the monitor refresh. We may see the CPU relax a bit if we have a cap or VSync steer in place, that's the plan.

So what do you do? We have to choose a compromise that serves best. Knowing we need an overhead is just a start. It can't cover all aspects of the simulator and heavily laden addons or AI traffic starting up, you'll see stutter then. But for minor glitches a few percent showing on the main core can fill in most of the time. It's just one way of setting up.

Fly in a straight line and things look more or less the same each frame. In a glider say when turning all the time or fast low flying, try to turn settings down so that the scene changes don't affect the flow so much. It soon becomes apparent the capacity and throughput setup of the sim is important when there's plenty of turning. Add in more detailed scenery and that's a similar effect in that there's more to put into view.


Steve Waite: Engineer at codelegend.com

Share this post


Link to post
17 minutes ago, SteveW said:

A two second stutter needs a 27GHz CPU to handle it. lol. Variance in the speed of delivery is what you see especially down at 30Hz or below.

With FSX we could half refresh with fullscreen exclusive mode. On a 60Hz monitor it looked good steered to 30fps (VSync is not a hard cap). But in the desktop window this doesn't work for FSX. With P3D it's only ever a desktop window and so we have the VSync=On setting when used with Unlimited slider 0, we get the GPU steered to the monitor frequency. if that's 60Hz and we want 30 we need to look at options. NCP and RTSS come into play. Or below 30fps try out the Locked slider, that's hard on the system.

 

I don't understand why after so many years, with all this apparent understanding, a reliable, solid solution cannot be offered?

Why are we even allowed to push sliders to settings beyond what the system can cope with?

You are very quick to respond to my queries with techno stuff, yet it seems this knowledge isn't being applied to a commercial solution. The stutters continue.

The developers and the hardware should be working out the stutter limits. Not the sim flyer.

And nobody has yet responded with any definite reason why my fast hardware was 100% loaded the other day with everything on minimum settings.

 

Share this post


Link to post
Guest
This topic is now closed to further replies.
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.
×
×
  • Create New...