These simulators rely on overall performance of system resources (storage I/O, Networking and so on), v5 even more so. Therefore HT On should be able to improve things overall.

However, we can't Improve fps by switching Hyperthreading (HT) on, unless those system resources are allowing better connection of resources to the main task of rendering the scene.

Switching HT on alone will reduce fps because the first core will be forced to share two main tasks of the simulator that can mean a drop in throughput to the main task up to 40% in worst cases.

So in order to test if HT on can help us we apply an Affinity Mask with HT on.

Supposing we have a six core CPU, we could apply an AM that allows only one task per core such as 01,01,01,01,01,01 binary (1365 decimal). With that we can find out if the improved system resources, now on 11,11,11,11,11,11 (4095 decimal) running with Hyperthreading can make a difference. In the case of AM=1365 the simulator 'sees' the same six cores as it does with HT off 111111 (63 decimal) and so then that program works identically to how it does with HT off.

In short HT Off reduces system throughput, HT On must be used with care.

 

4 minutes ago, SteveW said:

These simulators rely on overall performance of system resources (storage I/O, Networking and so on), v5 even more so. Therefore HT On should be able to improve things overall.

However, we can't Improve fps by switching Hyperthreading (HT) on, unless those system resources are allowing better connection of resources to the main task of rendering the scene.

Switching HT on alone will reduce fps because the first core will be forced to share two main tasks of the simulator that can mean a drop in throughput to the main task up to 40% in worst cases.

So in order to test if HT on can help us we apply an Affinity Mask with HT on.

Supposing we have a six core CPU, we could apply an AM that allows only one task per core such as 01,01,01,01,01,01 binary (1365 decimal). With that we can find out if the improved system resources, now on 11,11,11,11,11,11 (4095 decimal) running with Hyperthreading can make a difference. In the case of AM=1365 the simulator 'sees' the same six cores as it does with HT off 111111 (63 decimal) and so then that program works identically to how it does with HT off.

In short HT Off reduces system throughput, HT On must be used with care.

 

So, what about 8 cores? What am for that? 
I introduce stutters with HT on. Is there some magic setting? I’m using VRR option, so no frame lock. 

6 minutes ago, Ianrivaldosmith said:

So, what about 8 cores? What am for that? 
I introduce stutters with HT on. Is there some magic setting? I’m using VRR option, so no frame lock. 

You don't seem to have followed my post. Perhaps read it again more carefully.

1 minute ago, SteveW said:

You don't seem to have followed my post. Perhaps read it again more carefully.

I’ve read it, and I’m confused, hence the question. It’s more computer tech speak, when all I want to do is eliminate stutters and fly... Seems like a need a computer degree. 
So, I’ve got no idea, can I leave HT on, on some cores and not the others? Does the sim need core 0 or can it be excluded? 

We are talking about computers and you asked the HT question. I thought you understood the basic concepts.

So to start let's insert 8 core where I originally put 6 core:

"Supposing we have an eight core CPU, we could apply an AM that allows only one task per core such as 01,01,01,01,01,01,01,01 binary (21845 decimal)."

 

 

9 minutes ago, SteveW said:

We are talking about computers and you asked the HT question. I thought you understood the basic concepts.

So to start let's insert 8 core where I originally put 6 core:

"Supposing we have an eight core CPU, we could apply an AM that allows only one task per core such as 01,01,01,01,01,01,01,01 binary (21845 decimal)."

 

 

So, Basically leave HT on and use an affinity mask to mimic it being off in P3D? 

Yes. So with one task per core we have the same running simulator as we do with HT disabled 11111111=255. You can copy paste the ones into your calculator set to programmer mode and paste into the binary field to see 255.

So an 8 core HT Off no AM is in fact AM=255, one task per core. HT On one task per core = 21845 - you should be able to deduce that.

Use core zero which in the binary value is the least significant bits 0 and 1 - the rightmost '01'.

Edited May 28, 20206 yr by SteveW

3 minutes ago, SteveW said:

Yes. So with one task per core we have the same running simulator as we do with HT disabled 11111111=255. You can copy paste the ones into your calculator set to programmer mode and paste into the binary field to see 255.

So an 8 core HT Off no AM is in fact AM=255, one task per core. HT On one task per core = 21845 - you should be able to deduce that.

Use core zero which in the binary value is the least significant bits 0 and 1 - the rightmost '01'.

Ok, thank you. I’ll try it out. 

You can think of the simulator using cores like this: The rightmost 1 (HT Off) or rightmost '01' (HT On) is the most important task, that governs the fps available. The other cores run in parallel to each other (more or less) to deliver the scenery to the main core - the background task. In reality there is one of those other tasks to coordinate the parallel tasks so that the main task can run free without the need to coordinate the background task.

Remember that HT cores are split into two Logical Processors (LPs) which look like whole cores to the simulator.

The more you split up the background task over more cores, or LPs, the more you eat into the overall system throughput. That eventually slows the whole computer. So with 16 cores you might restrict those to less than the available core count or LP count. We can see that HT on with no AM allows 16 Tasks when there are only 8 cores.

The main thing is that we can't really improve fps without reducing the settings, to reduce the number of objects to paint in the time between frames. Or increase the frequency of the CPU clock so it does more in the same time.

What we can improve with more cores is the time things take to load up, the amount of work the background task can do in parallel. Keeping in mind that too many use up too much of the system and push out the precious system resources.

HT enabled increases heat because it does more work in the same time. That is the work done to provide the data for the main task - not an increase in fps. So we must be sure with overclocking that we are not too far up the heat curve already with an extreme OC.

Edited May 28, 20206 yr by SteveW

And some of those denying HT tend to deny coronavirus as well to some reason.. 😄

Edited May 28, 20206 yr by Dirk98

10 minutes ago, Dirk98 said:

denying HT...

I upvoted because it is fair to say there is a problem of HT enabled getting a bad name and that is a shame as it can be a benefit in many systems.

10 hours ago, SorensenDK said:

@Mace Could you share some information on your setup, setting, add on etc? Could be interresting to compare to a system that does not suffer from stutters. And do you experience a FPS loss over time, so that when flying from A to B, and landing at B gives you less FPS at that airport than if you would depart from there?

I do not not experience an fps loss over time, in either P3Dv4.5HF2 or P3Dv5.

You are running 3 displays...so I think Gerard's setup may be of a lot more use to you than mine.  I run 4k @ 30hz (or sometimes 50hz or 60hz) but only on one display, with a 1080ti.  You have an entirely different set of performance challenges with you running 3 displays.

I run an 8700K at either 4.8 or 5.0 (this time of year I usually turn it down to 4.8 as my h100 cooler is a bit light for what I ask of it), with hyperthreading enabled.  In v4.5HF2 I am running an affinitymask, where core1 is excluded (i.e. 11 11 11 11 11 01).  This frees up Core1 which allows its parent core0 to run full blast.  I have changed that over time from various other AM's but presently I'm getting really good results with the above.   I also run my add-ons with the FFC mask (that is hexadecimal) which puts them on later cores (in other words, keeps add-ons OFF of Core0 and Core1.   I do that via a batch file, which if you'd like I can post.  I run the batch file first, which is a series of "start..." commands and runs Pilot2ATC, UTLive, LittleNavConnect, ActiveSky/ASCA, and SimSounds.  Then I run P3D.

In the sim (4.5HF2) I have three settings profiles saved.  All of them use Unlimited with vsync and TB ON.  This I found gives me the smoothest, most stutter-free flight.  My most luxurious profile ("General Settings Profile") has most sliders right and many shadows on except for Autogen Radius (medium) and Autogen Buildings (a known fps detriment).  My most draconian profile ("London Night"), which I rarely have to use, disables HD lighting, all shadows, and has AG buildings down even further...this is a profile I might use at Heathrow at night, where shadows and visuals don't matter so much, and I'm able to maintain my framelock.  Vsync is effectively a framelock on my system.  My other profile is "London", which implies London Day, and allows me to hit my framelock in all conditions in the worst location in the sim (Heathrow with weather and AI and complex addon airport and aircraft).  If your fps can hit your framelock (vsync) that is a big step toward smooth flight.

In P3Dv5 I have the same three settings profiles.  However, with v5 performing better, I have more headroom for visuals.  With that in mind, I am able to refresh my monitor at 50hz, or 60hz (although I typically still refresh at 30hz, for complex airliner ops), and maintain that fps (50 or 60) in rural areas.  This means my "General Settings Profile" is largely unchanged (it is still Unlimited with vsync and TB ON) but it allows me to get 50 or 60 frames totally smooth.  It's really nice.  And of course it is noticeable.  i've been here 20 years and I cannot recall anyone in the AVSIM subforum saying you can't see/notice over 30 frames, I don't know where that came from.  Maybe some other forum.  40-50-60 is way better than 30 *if* it can be smooth.  But smoothness is key.  I'd rather have 30 smooth than 40 stuttering, and I think most simmers are on the same page in that regard.  With v5, it is even better and doors are opening for us to have 40-50 or 60 smooth, at least with rural GA flying, and I'm still experimenting toward that end with airliners and urban areas.  With you running 3 screens I would not set my bar that high though -- first take small steps and aim for 30 smooth on all three, if that's possible.

10 hours ago, SorensenDK said:

Again, it is no so much about FPS, I have "plenty" of those, but a question of that even though you have good FPS, the sim still makes the stutters/pauses. I tried setting all sliders to the right, and flew with 12 - 15 frames, and then you dont notice the stutters, because it somehow runs more consistant (if that gives any sense?). I will now reinstall P3D completely again, and start all over without any kind of add-ons and dig a little deeper.

If I were you I would temporarily reduce my setup to just one screen.  Get that one display smooth and get your setup right for that.  Only then would I add a screen.  I would also temporarily run no add-ons, establish a baseline, then start adding add-ons one at a time and test for smoothness.  Again, Gerard's setup should be very helpful when you start adding displays.

10 hours ago, SorensenDK said:

Question: Do you think ORBX Global textures could have a negative effect on texture loading? I found out that if I reduce the texture resolution, it becomes much better.

Any advise are ofcourse still welcome - THX!

/Bjarne

 

In v5 I am (right now) running 2048 textures with Orbx Global, OpenLC Europe, and OpenLC North America.  I have never done specific testing with vanilla textures vs. Orbx and load times or stutters, but I would think that your texture resolution would have more of an impact on that than anything else.

My other hardware are Samsung M.2 drives (two of them, for OS and v4.5HF2), and I actually recently bought a straight SSD (1TB) which is presently holding P3Dv5.  I was running out of room on the M.2's.   SSD is plenty fast enough file access for us.  As far as mem goes, I run 32GB of 3200 low latency (I'm not at home to check but it was something like CL 14 or 15ns if memory serves).     CAS latency matters when building a sim machine.

Anyway, hope that's not too long.  I hope you find a smoothness nirvana.

Looking back at the conversation about stutters, I have an issue with my current build (in signature). I had a similar issue with my previous build (4790K and an 11GB 1080TI). The video card is the only common thread between the two systems.

I have HT on, temps are fine, internal limiter set to unlimited with vsync checked. My monitor is a cheaper 4k monitor with a refresh rate of 60hz (https://us.aoc.com/en/monitors/u3277pwqu).

I have a lot of traffic, and I'm willing to take the performance hit for that. On the ground in the NGXu at a big airport with add on scenery, I'll get FPS in the 20's. This is totally acceptable for me when on the ground. Once in the air, I'll see FPS in the 40's+

I get very strong pauses at a couple points. When AI aircraft load in a large chunk (flying into the NYC or LA area, for example), I can get a big stutters for 5 seconds or so. This isn't that big of deal to me, because I know it is a trade off. 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've considered a new monitor, but the large 144hz monitors are pretty pricey.

Not sure I'm really posing a question here, or if I'm just talking about my experience with stutters on two different systems, but any advice is welcome.

 

5 minutes ago, SteveW said:

I upvoted because it is fair to say there is a problem of HT enabled getting a bad name and that is a shame as it can be a benefit in many systems.

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.