Continuing the HT setup:

Once we have the one task per core in HT mode with the '01,01...' we get to the interesting bit. Looking at task manager CPU graphs we might now be able to see some activity on the second LP (LP1) which would be the second graph in from top left.

If we see activity and we have addon exe apps like traffic and weather, the jobscheduler may see LP1 as 'free' and utilise it. Instead we don't want that. First we can reduce the cores used by removing the leftmost core from the simulator AM. With the example 8 core HT on we can go down to 7 cores 00,01,01,01,01,01,01,01=5461.

Now back in task manager we might see that activity moved to the last core at the bottom right graph. If not we can use the task manager details tab and set affinity to some exe's that we know are running until we find the LP1 is inactive. That ensures we have full bandwidth on the first LP (LP0).

If that wins us the maximum throughput we can start the offending exe app with a batch file or an affinity starting app to corral it above LP1, or better to occupy the last few cores. Running the simulator again with the specially configured exe app we can now see LP1 is inactive.

We carry on like that until we get the result necessary. 

@Noel, I'll come back later to answer your Q.

2 hours ago, duckbilled said:

 The other time I get them is when the weather changes. I can hear the trim wheel spinning, and the NGXu reacting to the winds/turbulence. I'm wonder if there is a way to improve this with Active Sky settings or something else. I want real world weather, but I don't need it to change during the flight. I just want to load a snapshot of the world's weather at the point when I load Active Sky.

I'm still not at home to check but I think there is a setting in ActiveSky where you can set it to not update at all during the session.  Change the interval to zero (0) I believe.  It will download the snapshot when you first are at the gate setting up, and then it will stay.  

1 hour ago, Mace said:

I'm still not at home to check but I think there is a setting in ActiveSky where you can set it to not update at all during the session.  Change the interval to zero (0) I believe.  It will download the snapshot when you first are at the gate setting up, and then it will stay.  

Thanks. I'll give that a shot on the next flight. I think I misunderstood the meaning of that setting. I took it as the weather would be the same everywhere. In other words, if it is snowing at DTW when I take off, it will be snowing at CUN when I land. What I'd like to have is if it is raining at CUN when I depart DTW, I want it to still be raining at CUN when I arrive.

I've only been using AS products religiously for 15 years. Maybe I should carve out some time to RTFM😄

 

Edited May 28, 20206 yr by duckbilled

11 hours ago, honanhal said:

I have to admit it makes me a little crazy when I read here (on a regular basis) that you can’t see the difference between 30 and 60 FPS.  James

Here's a rhetorical for you:  could you see the difference between 30 and 60 FPS in a still scene?  I'll answer for you, No.  Now how about one where the scene pans at the rate of 1 degree per second?  No, again.   2 degrees?   10 degrees?  What is the point, in a blinded test, at which would you correctly identify the frame rate  significantly more of the time?

Of course we're looking at just what is behind the fact many folks see very fluid motion at 30 frames per second when the rate of change in motion is under a certain limit, somewhat person dependent I'm sure.  Compared to running on foot and changing directions abruptly in Far Cry 4 often times things move so slow in a flight sim that it becomes irrelevant from a practical standpoint.

I've said Holy Grail Lite is 30 fps of stutter-free, very fluid video.  And yes, 60 fps of the same we can call the Holy Grail.  But again, most of the time in a flight sim 60 fps isn't going to come into play.  And unfortunately anyway, in order to do Holy Grail w/ current hardware in a well enhanced P3D, there hardware just isn't there yet.  I do it now and again in the uber easy to process Dash 8 but frankly the difference is there for sure, but not nearly as significant a difference one gets from going to stutter-free video at 30fps from any kind of stuttering performance.

Edited May 28, 20206 yr by Noel

I second that. For slow motions like in a GA or airliner, lower FPS numbers suffice. Might be different with VR, I have little experience with that. So, please do differentiate when talking about FPS.

13 hours ago, Noel said:

Both unlimited/vsync to 30Hz/TB enabled, and unlimited/scan line sync to 1/2 of 60Hz screen using RivaTuner, yield fluid solid 30 fps w/o stutters.  Perhaps you can explain this:  w/ the former method the main thread core varies greatly w/ load, or so it seems.  Up in the air w/o a lot of dense scenery it will settle down to 38% or what have you in the NGXu, and as we approach great complexity the reported CPU load starts to approach 100% if I failed to set up the flight optimally for conditions en route.

With the latter method the main thread core pretty much sits at 100% (dips down to 94%, 97% etc on occasion) regardless of apparent complexity of the scene.   Why do the two methods generate such different main thread core loads?   One thing I like about the vsync to 30Hz screen is I can tell about when things will be overloaded so it's easy to set sliders correctly, whereas that is not the case w/ the RivaTuner method.  But...it seems the RivaTuner method may be getting me more total capability, more capability out of the main thread's core.

The latter method where you see constant 100% with RTSS is the same on the CPU more or less but there's a task that occupies the remaining percent only to use up the activity counters which keeps the jobscheduler from allowing threads there. Set up without RTSS then invoke RTSS.

http://www.codelegend.com/forums/viewtopic.php?f=2&t=698 

Edited May 29, 20206 yr by SteveW

@Mace I will try to hack my way through the slightly hars argumentation in this thread 😄 Thank you very much for you indepth answer. I actually tweaked my RAM and tried HT OFF, which seemed to give a positive result. But that is really the problem with P3D - som swear to HT ON others HT OFF, and I do suspect that each individual has better performance with their result, as some argues AM is senseless. I really dont understand the theory behind AM, but maybe I should try to read up on that to see if I can do something about the 100% CPU use by P3D

Thx again for your time 🙂

/Bjarne

 

If you read the posts you can see that HT on is useless without an APPROPRIATE AM. There's no such thing as no AM.

...Imagine if I came here and said I don't know about Kohlsman? We can talk about VSync, FFTF, Monitor refresh, Hertz, frames per second, memory timing, CPU frequency etc. etc. But leave out HT and AMs? Doesn't make sense.

Here's another one: Let's look at someone using a low FFTF setting to apportion more time to fps and less to loading data. Suppose they have HT Off. They could load data faster with HT On with an appropriate AM, offsetting the loss to data bandwidth from the lower FFTF setting.

And another: Say I have an 8 core HT off no AM, and also I have a 14 core HT Off AM=255? What's the difference? None - they both use AM=255. 😊

So this discussion is about stutter. What is stutter? It is where the simulator loads more stuff and takes time - right?

Now take your HT Off no AM CPU and run up the scenario a few times, with a stopwatch measure how long the scenario takes to load up to the same point. Start up the sim a few times. It's got to have a chance for the caching algorithm to work things out, it's a kind of learning algorithm. 

Now turn on HT, no AM just HT On. Again start up the sim a few times. Measure how long that scenario takes to load up. It takes less time. So if it takes less time to load up, surely as eggs are eggs, that means it loads data faster. If it loads data faster then perhaps that can help with stutter.

Our problem is to utilise that extra bandwidth without knocking that main task of rendering fps. Not so simple I agree.

I can't see why anyone would insinuate that AMs and HT are not relevant.

Why pay more for HT? Because it is the optimisation of a core, it utilises bandwidth that would otherwise be lost to context swapping.

 

 

Edited May 29, 20206 yr by SteveW

2 hours ago, SteveW said:

Why pay more for HT? Because it is the optimisation of a core, it utilises bandwidth that would otherwise be lost to context swapping.

I've had such good results w/ HT off I'm thinking it is likely not worth the extra 10 degrees Celsius, though core temp w/ HT under load is still under 70C.  Since stuttering is no more the only areas I can conceive of improving on is:  1, ability to bring in more objects, i.e. set some scenery sliders a little farther right, and they are already kind of good enough and 2, to see if using more LPs to bring in data will reduce the risk of 'long frames', those 1-2 second hard pauses.   Since using FFTF Dynamic I seem to virtually eliminated those already, but not quite!

3 minutes ago, Noel said:

I've had such good results w/ HT off I'm thinking it is likely not worth the extra 10 degrees Celsius, though core temp w/ HT under load is still under 70C.  Since stuttering is no more the only areas I can conceive of improving on is:  1, ability to bring in more objects, i.e. set some scenery sliders a little farther right, and they are already kind of good enough and 2, to see if using more LPs to bring in data will reduce the risk of 'long frames', those 1-2 second hard pauses.   Since using FFTF Dynamic I seem to virtually eliminated those already, but not quite!

It's only hotter if it performs more work.

...so you  could leave HT enabled and turn down some settings. 😁

5 hours ago, SteveW said:

The latter method where you see constant 100% with RTSS is the same on the CPU more or less but there's a task that occupies the remaining percent only to use up the activity counters which keeps the jobscheduler from allowing threads there. Set up without RTSS then invoke RTSS.

http://www.codelegend.com/forums/viewtopic.php?f=2&t=698 

Thanks for that it makes sense!  What is that 'task that occupies the remaining percent....'?   As you mention the main thread seems to be getting the same amount of work done using RTSS w/ a 100% load, 'same on the CPU more or less', but it's nice to be able to see when I'm overloading the main thread w/ too much work via sliders pushed too far right, and we don't get to see that w/ RTSS and no vsync in-sim.